 Cool, so we're five after Frederick. Oh, you want me to go ahead and share when you're going? Yeah, let's do it. Cool. There's the share Great so Welcome to the next network to today's network service mesh meeting It is also the next So before we get started, please make sure that you add your name to the agenda's list So as always, let's do a little bit of Agenda bashing So is there anything that anyone would like to discuss that is not on the meeting? I Would like to ask is it possible that during the cube con? We we hold some kind of I don't know meeting or meetup I don't know what's the proper word for for this but kind of whoever visits there and is somehow participating in the project To sit together and talk a little bit through the project and all that the birds of feather sessions, but maybe I would say absolutely what we've historically done in the past In places where network service missions had a presence and we just haven't gotten the wiki page updated they're very the you know the the events page on our website updated for this is Typically we you know that there's sort of two kinds of get-togethers that I would describe there One is the we actually get together and we try and hammer some things out sort of a working session I think that's super important and we'll see we can try and find a better place to do that Typically cube con has some sort of semi public spaces for this kind of stuff where you can you know You you don't get privacy, but you can get a bunch of people together around a table and hash things out We'll probably take advantage of that the other one that we've traditionally done in the past is to do an SM happy hour So we you know find a nearby bar in an evening and we basically say hey if you're interested in network service mesh You know come by here for an SM happy hour, and we tend to get pretty good attendance of those as well With folks turning up and sort of just could be saying about network service mesh So I expect we'll probably do both, but I think what you're saying is could you please bloody? We'll get your event page up soon so that we can all see where we're going yeah, I need it mostly for scheduling because You know you have to plan these events otherwise you get lost at some point so no, and I do apologize I know most people actually do plan and schedule as a sort of a matter of personal proclivity I don't and this makes me less than it means it less than obvious to me that I need to get these things out there, so This is super cool. Let's go ahead and take an action item For getting the site updated Actually question. Do you want to make a lie? Sort of cut your teeth a little bit on on updating the network service mesh site. It is just another get repo So let me go ahead and take down Action items didn't do that bold Yeah, so if you want to go ahead and update that you can see where the other event pages are Hey, yeah, and if you could add me as well, I'm not sure if I'm already there, but in terms of hacking up the network mesh Site sure Let's see Nicolay Is that it's that how I pronounce your name Nicolay Nicolay? Yeah, that's good enough. Okay Okay, cool. Okay. Thank you guys. I appreciate it Good awesome Cool. So I think we were on agenda bashing Frederick That's right. So Is there anything that that is not on the agenda that people would like to discuss right cool Okay, in that scenario, let's go down the list of events So we have the Fido mini summit on December 10th, which is going to have two discussions one of them by Arroyo networks and the other one by Tom Herbert and So that is going to be co-located at kubecon kubecon is from December 10th through 13th, and we have two Two sessions that we're going to hold one is an intro to network service mesh. You know, there is a network service mesh deep dive so We are actively working on a network service mesh demo and Simultaneously, we're looking for any media or anything that people can put out there I guess they like blog post or videos or source podcast or so on that people want to produce and Start getting them out there so that we can have them ready for kubecon We also have a Well, rather there is an event called fosdem Which is has a networking dev room on February 2 through 3 and the call for papers for that is listed in the agenda Remind me where fosdem is was was it in was it in Brussels or I Something of my gut wants to tell us to say Amsterdam. I don't remember specifically though But I know they hold it the same place every year It is Okay, cool I think call for papers is over now. Maybe that's the lighting toes are still active but I Think the call for papers is still open for fosdem for At least my calendar for a little less than a Than a week for the for the the networking dev room Because each dev room holds its own CFP right and so we have a Forever a quick a quick question On the FDIO mini summit Ed and we had spoken about this in the path path past. There's going to be a demo Place or location or Time now this again. This is the FDIO mini so I mean that this actually this this is not the FDIO mini summit So the FDIO Fido has a booth at cube con And one of the things that they will be highlighting there at that booth is a demo of network service mesh Now I expect that demo will be a little bit more of rah rah look at the good things that the VP and Fido Do in the network service mesh context, you know because it is their booth But there there should be demos there, okay? Okay, very good as you know, we were gonna demo or are assembling an app to show a another VPP Specific app so I'd like to have some sort of visible tie-in or at least a little nod To NSM as part of that Yeah, no, I think a lot of things when you're talking doing things like this that cross multiple boundaries Become a question of emphasis, right? So for example In the Fido booth, obviously you would want to tell people why they care about our service mesh And then why Fido is awesome in that context, right in different environments You you might be much more focused on network service mesh and you might not focus so much on the fight of these Okay, you know, so I think it's more a matter of emphasis because we were doing a lot of good stuff together, okay Hey, and back to the blog post I guess on item 411 a couple of things real quick So I've got a couple of blog Content streams that we could pursue. I had sort of done one initially with CNFs and legato and VPP Frederick, I know there's the the 12 factor apps and by the way I'm way more fluent in Hugo right now, so I don't know if you saw the format of that But I would be happy to to pursue another template to make it more compelling But that would also be something I think we'd want to at least point towards and maybe even summarize In sort of a separate blog So there's a number of things going on at least in this content And so I'll reach out to the team separately to just Figure out the best way to assemble some of this material quickly and ready for cube gun Yeah, that sounds great to me. So any help in that area is definitely greatly appreciated Yeah, I mean one thing I would point out at Chris is I know a whole bunch of us are typically on the IRC channel Yeah, we'll call people out there when you guys, okay, that's fine. I'll take I'll do that route. Thank you Cool. Awesome. Um, so Cool back to you further Well, is there are there any announcements that anyone has that Our announcement list for today is looking a little bear Okay, no announcements. Let's jump straight into the main agenda. So As of yesterday, we now have a faster and lower cost continuous integration system. So In effect, we've done a couple things. Number one is we've made use of packets. They have a They have a few images that are on but it gets you to call them fast boot And so they these are instances that spin up in under a minute And so simultaneously we also ended up Using a cube admin to do the initial install on them which Brought our entire build system time down from was originally around 20 minutes to between five and six minutes Um, so for the people on uh from Volcar also have some feedback for you later on That I think would be useful because I would like to eventually move back to using the cross cloud stuff So I'll catch up with you later on so I can I can tell you some of the findings that I had and What drove this particular this particular path? so anyway, so if you if you If you commit anything It's simultaneously. It's also it's also driving the the packet our make machinery. So if you go into The If you go into the git repository and you check it out and you type make packets start and after you've created a Variable because you would take an answer file and I'll put the template up for that pretty soon Then and you just fill out like the token and so on Then it'll also spin up a system that's ready for for your test to run. So I'll write some documentation on how to run and how to run the test and it's the same machinery that also drives the The local cube admin the local vagrant And ideally it will also be the same machinery we use to drive Other clouds is as well from command lines. You can do like make Gce start or eventually you'll be able to like make aws start or so on Um Okay, so Straightened so we're going to go into the right now. We're using a different board. So historically we have the agenda board right now we've switched because of the focus of the community we're focusing on the cube con demo project board so board number two So Let's start with the things that are that are done so We have starting from the beginning Made some fixes in terms of in terms of some of the code Uh, a big a big entry has been the vpp data plane with a mif mechanism Um Ed your name is on that. Do you want to talk about that a little bit? Well, I'm actually not I'm going to file it, but I'm not the one who did it. Um, so that was actually done by um That was actually done by ilia, I believe Oh, yes Hi Cool. Do you uh, would you be up for giving like a a very short description on what the mif mechanism is for people on call? Yes, uh, my mechanism. Um it creates a file for Socket file for client and for end point And if we have direct, uh, we don't use VPP if I mean both sides have Memif they choose memif and If they choose one side, uh, for example kernel and other site is uh, mif so that we will create mif in vpp and Now it all works fine. And so I'm working on the VPP based end points and VPP based clients and points is almost finished. I think and I hope I fixed some issues from pr Yeah, and that that's good because then we can run sort of end-to-end Um, the mif connectivity and we have sort of templates for people who want to build You know more complicated network service end points than an icmp responder Um, but god knows icmp responders are handy Yes That's all I think Great So we've already covered the nsm ci uh We also have removed the requirement for huge pages for the vpp container, which will make running your Container a bit easier We've added a script For vagrant to ease the creation of the local local cornetes That is suitable for network service mesh So this is also part of the machinery that that I spoke about before And finally we're now exposing a monitor cross-connect service northbound from nsmd Hey ed is is that appropriate for the monitoring stuff that we were talking about last week That that's exactly specifically for the monitoring stuff So that was that was work that that andre so beloved did and Effectively what it means now is In principle and again, you never know till the integration test is finished in principle. We should now be exposing northbound um, you know cross-connect events um So that can be consumed by the skydive integration But probably even more interesting for the guys doing the skydive integration is in that commit. There is a super well done Test that stands up essentially mock server that will just emit events for testing purposes And uh, if you if the skydive folks follow that example, it should make it super super easy For them to do the development of their integration Nice, and so is there any uh documentation or like how how are we going to transfer the the knowledge to the skydive people? uh, so I I've I've been pointing this guy. There's an issue for this where I've captured much of the information about the skydive integration Um, and I've also got and I think it's linked to me issue. This is the indian progress column I've also got a cute little slide deck that walks through some of the answers to the questions that they were asking in irc Uh, which we can talk about after we talk about the board at this time Okay, well, um go ahead and add it to the bottom of the agenda then um great and so uh We have We also have uh two patches that are currently in review. Uh, one of them is to enable the vx land mechanism in the vpp data plane Uh, which means that we are on the way to having a remote cross-connect and We there's also a vpp agent based icmp responder and so I'm not quite sure what that means. Uh, See who is on this All right, ilia. Yeah, I'll let you discuss all right Can explain what does it mean vpp based? and point as I find out uh, that's a point that expose a vpp agent, for example, uh You can have some kind of stuff in vpp. It's has It's over vpp. I mean the point has over vpp agent and We can connect with the page and from client for example to the page and from end point and great cross-connect between them If I have correct understanding And Yep, no, you're you're you're good And I I've already gone through and reviewed that there was basically just you know one small net. So hopefully that'll go in very shortly Nice. So is this uh, specifically an icmp responder? Or instead of being in the pod the vpp agent itself is the one that uh, the response Or rather So basically effectively they're they're the vpp agent is literally just a vpp instance together with something that exposes g rpc the controller Right in the data plane. We use a vpp agent in the icmp vpp agent icmp responder It uses a completely distinct instance of vpp agent Running in its own pod in order to provide the icmp response Does that make sense? Okay. Yeah, that makes a lot of sense Yeah, and and and this is you know You're super super convenient because right now it's doing icmp response, but if you wanted to Have it do something more complicated and vpp does many many many more complicated things You've got a good template to start from Great. So what I'm so what I'm hearing is that right now it's an icmp responder But it's also going to be the basis for a vpp agent that you can then use to create network surface Endpoints on to do things other than the cross-connected me in the data plane. Is that is that a good description? Yeah, it's basically the basis for writing network service endpoints that are using vpp inside themselves nice well And uh, we have multiple things in progress. Um, I'm not going to go over too much of them unless someone wants to drive Drive into them We are implementing a remote network service client using nsmd There is a So of course one of the things that uh That we definitely need to talk about is the skydive integration a bit more And is that something we want to do now or is that something we want to talk about when Uh in your slides that that you have next in the agenda I I'd say that's mostly up to david and michew They're the guys doing you know sort of leading the charge there And you know if they want to go ahead and drill into that a little bit. I'm perfectly delighted to Okay. Well, it's up to um Some of the skydive people do you want to have do you want to have a discussion on it right now? Or do you want to uh talk about it later on? I don't know if david is uh is present here, but uh We started I've been starting Developing a client that will be uh in the future the probe hosted in skydive Based on the on the recent patches uh streamed by Uh, I don't know stream. I do I think And uh, it's really useful and should not be So hard to have a a probe for for skydive based on those Development um What we have to focus on is the architecture you started the Uh a document on that head Oh, well, did you stick the link to that? Are you talking about the the slides I put together or is that something different? Yes That you talked about I wouldn't want an architecture per se it was more of a waving my hands wildly trying to explain what was going on Yes Okay, so we we need some kind of uh sequence diagram to to uh to agree on the core flow It would be really useful and uh I think you're drawing such a background So if if david if you could you if you could share that here as well And if you could stick it in the issue, uh, because you you've done a super good job of tracing out the sequence of events Uh, oh, okay. And uh, by the way, may I ask some questions about the slide you draw yesterday? Sure one second. Let me actually bring them up Yeah Hey, uh while you're bringing them up and um, yeah, I would agree. We absolutely need some sort of architecture picture Um, this may be part of it. Uh, ed and thank you so much for uh helping craft these up yesterday and answer some of David and myself's question. But um, yeah, we we need something because there's a lot of terms flowing around here and I I just I don't personally have context as to where these pieces are so Whoever talked about the call flow be happy to work with you to uh To make sure that there's at least some visuals On what we're doing For cube con and certainly what we're doing moving forward with skydive Yeah, and and so you you you had some You know, I think we may have jumped ahead to the side of the agenda effectively Uh, do you mind David? If I do just a quick run through them for the benefit of the rest of the call and then we can get your question Uh, okay. So I can can we jump to the last slide? Uh, the question David was do you mind if I do a quick run through for everybody else in the call and we can get the questions? Oh, okay Cool. Cool. So um real quickly that this was a slide deck that I put together because David pinged me on irc Yesterday was asking a bunch of questions and I realized that pictures are going to be really super helpful Um, and so one of the things that I realized is that they needed to be clarity about the fact that there are different ways to look at the topology Right. So if you look at it from the point of view of a network service client or a network service endpoint The world really looks like this right network service client has a local connection We mark local connection in our Legend has a local connection You know some kind of Thing happens. It doesn't know what it doesn't care Um, and there's a local connection from the network service endpoint that it's going to And so this is just one logical line You know point-to-point cross-connect between them as far as they're concerned Um, and so that's the view that the network service client from the network service endpoints have in the world Now the network service daemons the smd's that are running on each node In the single node case, you know, they have a different view of the topology Right from the point of view of the nsmd. You've got a network service client. It has a Um, it has a connection a local connection Into the data plane the data plane has a cross-connect that cross connects that to a different local connection That is going to the network service endpoint And that's the way the nsmd sees the world topologically for things on the same node For things on different nodes when you've got the multi node case what it looks like to a particular nsmd is I have a network service client. It has a little connection to a data plane I should put the cross-connect in here as well. Apologies. I should fix that in the picture But it essentially hits a similar cross-connect to a remote connection Um, and the remote connection can be something like vx of vx land tunnel Right and those are the points of view of those components the network service client or network service endpoint And the way the nsmd see the topologies they understand I have one question that if if you allow me so essentially my understanding is that the cross-connect is not part of the data plane itself, right? Well, the cross-connect happens in the data plane Okay, I mean at least the the cross-connect object that we're creating Is not well, yes the cross-connect object we're creating Effectively the cross-connect object The nsmd when it talks to the data plane it simply says Please create these cross-connects from me. You know, I've had a connection over here and a connection over there Please link them into yourself and cross-connect them And then the cross-connect objects that are coming northbound They come northbound from the data plane once that's finished because now we've got them And then they come up from the nsmd towards your topology monitoring. I think I have a picture for that subsequently as well Okay, so Is it yeah, okay? Thanks. Uh, uh, is it always a point-to-point connection or I mean It's not like the cross-connect is not kind of bridge or any other logic is just if you need a bridge If you need a bridge a bridge is the network service Okay, good. Okay. So you can totally have all the bridges you want Um, but that's a network service and this actually turns out to be phenomenally helpful because bridges are complicated um, and so by making the bridges a network service number one we basically um Network service mesh itself doesn't have to deal with that complication It just has to get things to that network service And then the second thing that that actually is kind of important from a sociological point of view is There are a bunch of people competing in the bridge space We don't want to compete with them They're doing all kinds of wonderful things Well, um, and so yes, if you have a bridge we can catch you to your bridge But we ourselves do not provide a bridge Okay, thanks cool Um, and then the last apology view is what things look like topologically at the view of the cluster And this is probably what you want to bubble up to skydive in some sense So from the cluster point of view essentially you've got a network service client It has a local cross-connect to a data plane Or it hits a cross, you know where it gets cross-connected to a remote connection Which goes over whatever your underlay is, you know, the real connection might be vxlan Then it comes into the data plane on node two and it gets cross-connected to a local connect cross a local connection to the network service endpoint on node two So This is one of the things I think that makes it simpler is different parties in this have a different view of the topology The network service clients and network service endpoints have a super simple topological view It's a point-to-point view, right? At the level of an nsmd The nsmd only really understands the stuff happening on its node So its topological view is not all that complex either And then when you knit them together at the level of the cluster Then you get this slightly more complicated view of how the topology comes into existence Does that make sense? But just from an nsm view, uh, you will be able to to know which which Endpoint you are connected to So from the nsm point of view, you know the name of the network service endpoint that you're connecting to Um, you don't necessarily know where you know the name of the network service endpoint And you know what network service manager is managing it. Um, you don't necessarily know You know things about it like isn't using them. I ask because if you're if you're dealing with the remote case That's not your problem So, you know, you know, just the the identifier of the endpoint Yeah, you know the network service endpoint identifier, correct. Okay Um, whether it's local or remote Cool, and then the the other question that came up was in talking to david He sort of started asking questions about the flow of packet through all of this Which it turned into a whole series of slides that I think are probably helpful So I've used a smiley face as the packet because it makes me happy So a packet originates in the network service client It goes over the local connection Of that network service client, which is the only part the network service client actually sees of this chain It gets to the data plane the data plane cross connects it to whatever the remote connection is Which typically involves putting an in cap around it. So I put an in cap around our smiley face You know that thing goes over whatever your underlay is Which then arrives at the data plane on the other end where it gets decapped Then it gets cross connected To the local connection of the network service endpoint And gets delivered to the network service endpoint And then the last slide the one I think david has questions about I went full ideographic programming um Because you know, he was asking sort of how this related to things and so you've got the network service the Damon it exposes the monitor cross connect API which will stream back a bunch of cross connects with the skydive probe asset And those cross connects are just you know a cross connect Which I've represented with little diamond is just a payload type which is ethernet And information about a source connection And information about a destination connection And it gets one cop one view of this from node one It gets another view from node two The thing that's going to be true is the just the connection here for the destination It's going to be the same With both reports So the cross connect that gets reported from node one It will have a different local source because it is different locally But it will have the same remote connection That we get From node two So when you've got remote connections between nsnds It will be the same connection object on both sides Whether it's source or destination Do they have the same ID? Yes, they will have the same ID Okay, same ID different source and the same destination and payload right Right, right, and they will be different cross connects because nsnd has its notion of a cross connect And by the way the payload is just a string of ethernet Or it is I believe it is at this time. Yes Okay, so currently we only support ethernet, right? No, we can we can support other things Oh, okay But the the the the truth of the matter is I for your point of view. I think it's just information you would report Um, it should match between both sides Now one thing I do want to be cautious about what this picture is It's the it's not the destination this that makes the connection is the same This could be flowing the you know, you would have things It's not the destination this is the remote connection this that makes things um You know that that makes this connection match Sorry, could you repeat that? It's the destination this that makes this connection match because actually Yes, okay, because actually from from and I I've screwed this up. I need to correct this um from the point of view of An sm2 For the cross-connect the source is the remote connection and the destination is the local connection Uh, yes makes sense. Yes. Yes, and I apologize. I screwed that up on the picture the first time What about the id? I mean What about the what what about the id the cross-connect id So the cross-connect IDs will be different Because they're objects like this cross-connect is different than that cross-connect But this connection this remote connection between them is the same thing So from the point of view of node one its destination and its cross-connect goes out as a um remote connection from the point of view of node two its source Comes in from a remote connection and those remote connections are the same on both sides They'll have exactly the same parameters Okay, so that means that I will have a list of I mean two lists of cross-connects that one list is from source to destination and I mean from from local to remote and the second one is from remote to Local and they may be out of order. So that means I may need to pair them together One other thing to be cautious of which is already by which connection IDs get issued Right. So the connection ID is always You know connection IDs are always created where you are going right, so If I am a nsm one and I request a remote connection from the From the nsnd on node two It's the nsnd on node two that will be creating the Connection ID and the connection ID is only guaranteed to be globe to be unique within the context of node two so you You will need to know What nsnd you got it from And and the connection ID because those two are what uniquely identify it within the cluster Okay, okay. Okay. Okay. Okay. So here comes the second question that I noticed that you put the skydive probe outside the cluster Oh, it doesn't have to be. I just didn't want to make I This was an artifact of the fact that if I make the cluster bigger than I don't know what to do Okay Okay, but uh, so is it a daemon said that each node have a skydive pod or There is only one probe That's fairly up to you guys Hmm, okay Okay Yeah, I mean you guys can decide how you want to do that. Um You know how how you want to do how you want to do that because actually either architecture is viable. Um You just have to decide what it is you want Mm-hmm Okay, Ed Ed super extremely helpful now I'd also like to see where this monitor cross connect server And client would be located And uh, and and uh, I guess david and uh the skydive colleagues. Yeah figure Determine where you think the best place for the for the probe would be and we would want to include that In an architecture picture Again, just so everybody has context about these movies I would actually I would stress we do the following thing because I think we were running at a time on this call Which is um, if the folks involved in this want to do a chat on irc after this we can hammer out these things I think pretty quickly um And I know among other things for example that david has done some really nice sequence diagrams That I think elucidates some of what you're discussing as well Okay, I'm down with that. Uh, thanks Ed Cool, excellent It met you david are you you down with continuing this conversation on the irc channel after this call? Yes, okay Excellent Cool. So frederick back to you all right, so Going back and Yeah, quickly, uh Question that do you have a link for that document you just showed? I'm pasted in here somewhere. I seem to have lost Going on it. It's it is actually Both the slides. Yes, got it. Thanks. It's also linked from the issue cool Okay, frederick really back to you this time great, so We have as well Some work being done to the network service mesh data plugin so Looking to dynamically expand the pull of device IDs Um, and do a very variety set of refactoring in order to make that better and more stable One of the things that That we're starting to focus on as well now that we have these various components up and running is also eliminating race conditions between which one should start up. So for example, if the data planes Starts up for nsm or should nsm start up for the data plane and we We believe that it shouldn't matter which one spins up first that they should Just do the right thing and so there's work done in order to In order to make that happen There is also work in progress for creating a ppp agent nsc that uses mif to perform its work and um Finally More work continues to be done on the vxlan mechanisms So So I I know I I know you had a patch in nicolai just before this call. I just think you'll look at it Um, so far it looks good. I just need to digest it Yeah, it's just not not tasty. I mean I just followed whatever the other guys were doing Trying to apply the vxlan logic there and This is what I got. Yeah Any review will be helpful Cool. Uh, it might be worth you pinging ilia on the irc channel. He's done a lot of sort of Data plane testing stuff. You may have some interesting ideas on how you could try and test it Okay, good. I will thank you. Cool. Cool. Okay, so I um So moving on from the from the project board. So we've already gone over the the slides. So we'll dive directly into Well, we've already we've already spoken about the architectural picture. Is there anything is there anything more we want to say about that? I don't think so. I think uh, the irc channel will hash some of these questions out Okay, great C and cf network service vnf and cnf data plane benchmarks and comparisons Taylor you're listed as the Person for this. So you have the floor I meant to change that mouthful Um You make it longer if you like. I don't mind No That's a little bit shorter Okay So I could do you want me to bring up a board? Share my screen Might be helpful visually Sure. Sure. Let me just let me stop sharing then you can share and I'm on the same thing We get a lot in motion um a lot done And there's a lot in motion With the open stack The biggest thing that we have right now is on this the vpp neutron driver So if anyone is there's not a lot checked off here, but there's a lot that's happening on this code base This one's really the biggest blocker for the open stack side So if if there's anyone That's on the call or you know anyone that's familiar with this neutron driver that uses vpp as the v switch for open stack then Please speak up or ship me a message He's working. Robert is working through issues um trying to debug stuff it works in the In a dev stack single node It's not working on the chef deployed like the official chef deployed open stack hasn't tested on that cola Which would be another one container based install We're trying to work out the bugs on that and Most of the rest the open stack should be done but we Haven't had a lot of chance to test because of this And let's see We have a lot happening with regard to the kubernetes side. So if I come back in here, I posted some so On the kubernetes side, we have clusters deploying with layer 2 working. So you can have the packet this is specifically on packet so on packet you can deploy a kubernetes cluster and Have the layer 2 switch set up as well as the worker node We've done the implementation a way that we could Take out the host worker node stuff and plug in nsm One area that we need to figure out and talk with y'all at some point about would be How are we going to work with the packet switch side? And most of what we were thinking for nsm as worker node They're still setting up the packet switch, which is what at least what we want from bear from zero to a working cluster So that'll be a discussion. We need to figure out. How is that going to be handled? It's currently not handled in the terraform Packet plug-in. We're having to do it external. We're going to contribute back to that So anyways need to figure that out Um the templating for the vpv switch to support the different topologies We're in that's in progress. I'm trying to figure out how to make it The most usable between kubernetes and open sacs since we're comparing um That's the ansible side. We have scripts that can reconfigure all of it for Docker most of the previous work was docker kvm That's all of the c-sit packet testing So trying to make it work for kubernetes And likewise the helm charts. So there's some issues with like cpu pinning and the dynamic configuration The way that they're implemented right now. So If if we went into this code base A lot of the way this is set up Again was for the kvm and docker docker setup so we can reconfigure These containers on the fly To make it work And there's a lot of things in here that we can take advantage of for tuning with docker and kvm And we have to find how do we do those things in kubernetes? So stuff like the policies for How the cpus are allocated and stuff Don't quite give us the um specific things that we were using for tuning before to actual core id's so figuring those out and What parts can go into the helm charts what parts need to go outside? And trying to make that as clean as possible so that once we have In a sim in place the whole solution is going to be more of the kubernetes way um, so anyways Cluster looks good. And now it's the pieces that run on the cluster as the focus once we have the helm charts. We're going to be Creating the different Topologies that we're deploying so the snake case where it's going to go through The v-switch as well as the pipeline and I Think I have I don't know if anyone on this call is seeing but here's a quick overview of what we're looking at so this is like a snake case where You're going to in the open stack. You're going to go through The vm and back out to the v-switch. This is vpp and then on kubernetes will do the same And then we'll have the optimized version where we can go from container to container or pod to pod for the The best case scenario So that's what we're targeting as far as that those topology cases um On the dev side that's affecting everything in packet one of the big problems that we've run into is limitations on how to configure vlans for the switches um depending on how you do assignments and stuff it can Change the way the switch Is configured including does it send the vlan tags back to the server? Does it not? Is it access port mode? We have maximum of 12 vlans If we try to do sharing we've run into issues where we can't assign the same vlan to multiple ports Um, at least via the web ui it seems to be available in the api So there's a lot of weird limitations and the visibility there um So trying to document all those and find the workarounds To make it work in packet I think that's it right now. Um, there's a lot of new documentation that's been pushed up ed kern Did a first round for the end user documentation what we're expecting if someone Doesn't know the project and wanted to come in and try to Re redo the results on packet. So here's what you would do and walk through. So we have this first round Um, we're going to keep filling it out We also have we've pushed up a lot of documentation on using the individual components like this is how to use the traffic generator With NFE bench and stuff. So this could be useful for other folks that want to use those This would work if you have your own kubernetes cluster and want to use NFE bench to Run traffic against it. You could spin this up and then go create whatever scenarios you want in a NFE bench And we've also put some stuff like the issues we've seen with the bias and other things on the packet machines for the quad intel Knicks, what do we need to do? How what do we set up with grub all of these things? So Trying to make more of that The tips and other things that we've seen in packet and all the testing available for others That's it for me and nothing right now for in us like requesting help immediately On the kubernetes side the one thing again would be anyone that knows Vpp And open stack that would be the the biggest area to help for that neutron plug-in Thank you very much Yeah, I I'll see if I can find anyone who As well, I'll look through my contacts and see if I can find anyone who knows Vpp neutron Oh, that that would be the first data stacks project on opnf a As well as the networking vpp project on open stack, okay, that's It's going to add that is perhaps we can reach out and see if they're really yeah And I just checked I don't have there are IRC channels online to see who might be listening at the moment And talk to them in a while Yeah, and in the long run we also want to have a Some form of an integration with with open stack and then with service mesh and so You know be able to cross that bridge between kubernetes and neutron and back again And so it'd be good to Start making some connections there in the in the near future um okay with that uh I think that Yeah, there's nothing else left on the agenda. We have three minutes left. Are there any last minute things or questions that anyone has? Great in that scenario. I'll yield you back two and a half minutes of your time Thank you everyone for attending and we will see you at the same time next week Goodbye