 Welcome to the call. So, again, for the folks who are just joining, a reminder of the meeting is recorded and automatically posted to YouTube. We usually start about five after when folks have turned up. I've linked into the chat again, so folks can go add themselves to the attendee page on the meeting minutes or add anything to the agenda they'd like to. Great. So, Nikolai, do you want to get going? Do we have Nikolai on the call? Yep, I will. Awesome. Do you want to share the... I will once again stick the link in here for folks who want to add themselves to the attendee list and or add agenda items. Yeah. Okay. So, I guess my screen is shared and should be seen by everyone. Yep. Good. Okay. So, yes, again, please add your names here if you didn't do so already. So, agenda bashing, I guess that we have added a couple of items already. If there's anything that you want to bring up to our attention now, now is the time or you can just add it on the bottom. It doesn't change much. Okay. So, the first thing here to discuss is the events. So we have a couple of them queued here. Mobile World Congress is the first one on the list, although not the first one. Ah, yeah, actually, yes, it's later this month. So, there will be a number of people going there. I guess, yeah, if possible, maybe we can do some meeting there. I won't be present, but if there are relevant people, it could be good to join and talk about NSM. So, on the network, on the service match day, okay, we still don't have network service match day, but on service match day, Fred was supposed to submit a talk and I see that he's here already. So, Fred, did you submit your talk? Nope. They actually updated the date. So, first of March, so, yeah, there's still time. So if someone is interested, it's in San Francisco, so if someone is there and wants to join, it could be interesting to participate there from NSM point of view. And we have the open network submit in North America, call for paper already closed. Did someone receive notifications? Are you aware of something? I think the notification dates have been pushed back. I've got some talks in there and I have not received a notification one way or the other. Okay. Yeah. In the background, I'll try and see if I can figure out when the new notification date is. Yeah, because they say that schedule announcements should have been like last Friday, Thursday, February 7th, but it's, yeah, good, LFN demo booth to showcase audio and SAM integration. Okay. Is this Lumina LFN? Who is doing the demo there? Usually that's probably Prem, who's at Lumina, but he doesn't happen to be on the call today. Ah, okay. Okay. So that would be a great interesting demo actually to watch and to demo. And if the relevant guys are interested, they can even show something on this call for the rest of us to see before the ONS. But I guess we still have time. Okay. What was this? This is the MPLS SDN NFV meetup or, I don't know, kind of conference there in Paris. I don't know why it's here. I think that some folks are attending to, yeah, not intending to attend there. Maybe more relevant for us is the container world. Yeah. Okay. We also have a talk accepted there. And we would like to see more details from Prem, but I don't know, is he on the call? I don't think we have Prem this week. No. Okay. Yeah. Maybe it would be interesting to see what was accepted there. And the week you went for NSM, at least to my view would be KubeCon EU Barcelona, where we target to announce our first release. I hope that we will be able to do a good impression there. And yeah, actually, in three weeks, we should receive the notifications, but we have supplied a number of talks, submitted a number of talks, or I guess that we should make it with something meaningful there. So Ed, do you have anything to add about the FDIO mini summit? So that's something we should be sorting out the next couple of weeks. So I don't have anything to add directly, but it's very likely there will be an FDIO mini summit happening. And call for papers is still to be done? Yes, indeed. Okay. So yeah, we'll follow here, I guess in the next calls and see how this goes. For the QubeCon and CloudMativeCon in Shanghai, the call for papers are still open. From what it says here, February 15th. So if someone is attending there, please notice that we can record here the fact of the event, or at least the application. And the last thing here on the list from the event that we have is the open network submit which will be in September and call for papers is still not open, but we are intending to apply there for sure. Okay. So the next thing that we have here on the list is the announcement. Is there anyone wanting to announce something that's not on the event list or not on the agenda? Something interesting that we... So maybe I can share something. So we were contacted with that by a guy that apparently is in a time zone which is not really suitable to attend the workgroup call, but we hope that he will be able to attend next time and share how to say multi cluster NSM with interesting approach. We'll see. I mean, interesting to see that not someone is working on this in an alternative way while we get. It's always a good idea. This space is very new. And so there are lots of interesting experiments going on. It's always exciting to see them. This is how we learn. Yeah. Okay. So let's hope that next time we're going to see something, even a demo or slides. Yeah. Okay. The next thing that we have on the list is the stars announcement. So we did this last time. So we need to gather, I think it was 300 starts. Yeah. And we were about 80 today. What's it now? But yeah, this is something that please spread the word. Ask your friends and, you know, allies on the project to star. We need the stars. Yeah. And then there are a couple of items which are marked for me, which means that... Okay. So the first one is the NSM release project. So as we announced, I think a couple of workgroup calls back. We started this release process and we're going to track it here on this project. We have a couple of items here in the backlog and a couple of them in the progress already. So, yeah, everyone can check this, but maybe one thing that is, okay, maybe two things which are worth noting. One is the auto healing that is going on in at least two directions. I mean, I mean, two people working on it in different PRs. And the other thing is that we, in different scenarios, by improving our CI, we are identifying unstable behavior and we are trying to improve this. And this actually is good because we are having a lot more use and test cases, which will allow us to improve our stability and robustness of the overall solution. So that's the current state. Of course, there will be a lot more to add, just that this is what's going on today. And I hope that the specs, which are due to be reviewed in this meeting also by it, we will have a chance to also generate more also other interesting topics that we need to be, that we actually make their way here in the backlog. Okay, then, yeah, last time we announced the spec about the NSM release process. And we asked for any review suggestions and, you know, any kind of help. I don't know, because we didn't receive anything, at least in the remarks here. Yeah, I think that we sort of come to the conclusion there were basically, there were, there was a small number of things that actually needed to be decided fairly swiftly. And these are sort of the things we need to agree on. One of them was the dates, right? What date are we going to pull a throttle branch for the release? And at what date are we going to actually, you know, put out the dot zero version, which is sort of the release candidate for us. And then on what date are we going to put out the dot one, which is the first, okay, we actually think this is a workable release. And you proposed some dates that we talked about last week, and they looked really good to me. And I didn't hear anyone else to whom they didn't look good. But I wanted to allow, I thought it was important that we have a little bit of time for there to be some discussion and consideration. And so we, I think we decided last week that we would sort of take a look at those dates this week and see how people felt about them, get any discussion about their placement. And if people are okay, we'll just proceed with those dates. So do folks have any thoughts, opinions or comments? It looks like effectively we're pulling the throttle branch about a week before we would do the initial dot zero release and then another week before the dot one. And the dot one is time so that we would have a working dot one release going into KubeConnyU with, it looks like you allowed about a week's worth of slack in the schedule for the inevitable things to go wrong, Nikolai? Yeah, actually, actually, there are two, two weeks in between the, you see, it's 14. Right, right, right. KubeConnyU is about a week after the 14. Yes, yes, yes, of course, of course. Yeah, definitely. So what was the expression man plans, God laughs? So I think probably wise, do other folks have comments or thoughts? So I do have a question. Is there like a clear like a feature list that I can go read somewhere that says definitively this is in the dot one release? This is what it actually works like that at this stage. Sorry, you were breaking up there. So I mean, I don't think we have that right now. I think you've got some stuff, Nikolai put together on the board of stuff that we're actually targeting getting into that. But part of it is, you know, people have to actually come and do the work. And open source projects don't simply don't end up being sort of centrally managed quite like that. I mean, you can come to consensus that looks like that. But my sense was, probably what we're looking at is that this particular one is sort of stability and security and that kind of stuff. Are there particular features you want to see in the dot one release? No, I just want to know what they are so I can go internally and be like, we should all take a look at this. And this is what you can do with it as of this release. Okay, I mean, we will definitely have such a list once the release goes out. No question, right? Definitely. But you're sort of asking for sort of a prospective, right? Yeah, I mean, just in general, right? Like, I mean, you're going to be able to set up these services and then in the sea, you know, you'll be able to write these services or whatever, you know, the SDK that Nikolai's been working on has this availability. Just, I mean, I guess, unless you're saying that, hey, look, this is a dev kit, and here's dot one of this dev kit, and it's bring your own code type of model. Yeah, I think but there's there's the service mesh itself. And that's that should be something you just compute control apply and there you go. Right. And then there is the things you might deploy on top of the network service mesh, which would be various NSEs. And then there is, as you put it out, the SDK, which would be this is how we make it super easy to write your own network service endpoints. Okay, I'm just trying to avoid the awkward, awkward conversations with like directors and VPs when they give me the office baseline of so tell me exactly what you do here. Yeah, that might be actually worth discussing in parallel is like how you know, it's an interesting thing network service mesh in terms of explaining it to different audiences. I've done a lot of this. And it's super funny because there's a set of things that I figured out that seem to work well with cloud native audiences, people who are used to running apps and Kubernetes, and they sort of not up and down and say, Okay, that sounds good. And you guys have seen a lot of them because it turns out when you, for example, talk to the NFV folks like you, Jeffrey, the use cases I usually show the cloud native guys are not so much the ones you're interested in. But you look at them and you're like, Yeah, I don't care about this use case, but I absolutely see where you're going, right? Because you're a network guy. So how to communicate this effectively to different audiences and sort of putting together some of that collateral for the release, I think would also be really valuable. Yeah, so here we have the list of the release materials. It's not really a feature list, the way that you asked to Jeffrey, but still I think that based on this, we will have whatever we release. So at least my approach for the time being is to try to have as more tests as possible, different test scenarios, proof stability of the basic functionality like define NSM, define a network service deployed within a single cluster. And if, you know, being able to change it at runtime, all these, you know, kind of basic things that you feel like you should be able to have from something that claims to be stable. Now, all the other good things about, you know, inter inter cluster communication, UNSMs, NICs, and all the other things that we're talking about in the specs, I guess that these things probably won't make it. We just don't have the time to do to do this. But if we do, it would be great, right? Well, even if it's super limited in scope, I think it always comes back to the documentation thing, I guess, is just having like an intro dev guide then, right? Like if it's, hey, we're gonna show you how to build your own network services than just, and there's an optional data plane implementators guide, but there should probably be like, like a pretty robust, like document around your SDK, Nikolai on, look, if you're gonna come, if the underpinnings are stable, is that a is that documentation or is that just? Yeah, yeah, yeah, this is in the docs. Yeah, we definitely definitely have meat around docs. No question. Yeah. You know, they're, they're gonna be super, super important, particularly for the first release going into KubeCon, because we're gonna have a bunch of people who are gonna get immediately interested, they're gonna want to take it off the shelf and do something. Yes. Yeah, I missed that master bullet there. I didn't see that. That was part of the document thing. Yeah, we have the containers released and so deploy artifacts, APIs. Yeah. Okay. I think one thing that's missing from that release materials, I mean, it's not functionality. So, so fine, we're releasing binaries, but what can I do with it? It's probably more, you know, even if it's a targeted aims of what you expect, I know you're saying, well, it's an open source community to do what it does, but, but you've got a plan for KubeCon, if it reaches a threshold and you release it or it doesn't reach a threshold and you dispose of the ideas. So, having that threshold in mind, I think is important. Okay. Good point. Anything else? Okay, so shall we show, shall we let this sit here for one more week and then we declare it stable, like done? Yeah, it's certainly at least the dates, right? Which are, I think the rest of it will evolve and improve. Like, you know, we've got bullets of the documentation, I'm sure we'll do better that over time, that sort of thing. But the key point in my mind is the dates at which we're going to pull the throttle branches, and do the dot zero and dot one release, I think those are the really important things we have to agree on. Lots of other things can be somewhat in flux. And getting them better pinned down is goodness. But dates are kind of a thing we all have to get on board with. Okay, so, okay, so if there are no other comments, then let's leave it for one week and next week we are going to go over the dates at least again. Good. So, the other story that we had happening this last week was this, this doodle that we did poll about the date of the dedicated architecture call. Jeffrey, do you want to say a couple of words about what happened? Sure. And so first, just the disclaimer, it's going to be the documentation call, not the architecture call. I think, okay, to keep, to keep things on track and focused, we should just focus like obviously, we'll review architecture. So if you're just trying to figure out what any of this stuff actually does, it's probably, you know, a good one to call but I feel like architecture calls a loaded term, which then implies that we're actually going to argue about how the architecture should work on that call. And that's not the purpose of this one, that one should be relegated to like one off. So a couple things though, that's like, for the whole group, I added a few more bullets here is, so the recordings and meeting minutes, that makes sense. So yeah, Ian and I, we've started a rough draft on a glossary, I'm pretty sure 90% of this is wrong, but that's okay. I'd like to tackle this first. So first off, I know that it is traveling right now, Nikolai or Frederick would either of you be available for tomorrow's call? I will. Okay, perfect. So, Nikolai, then I think tomorrow what we want to do is this is like the bottom layer of our, you know, the foundation of our houses, we need to get all of these terms satisfied. There's a couple of things that you know, and some of the specs I've called out like, you know, we've got data plane there, but depending on which, you know, spidery splice slide deck you're looking at in SMD, sometimes refers to the demon and other times it refers to the data plane, things like that. So this is what I'd like to tackle with you tomorrow, because I think you can help us correct some of the things we've gotten wrong and fill in some of these blank ones. And then from from there, we'll continue to evolve. I've secretly been trying to get Ed to do all my work for me by asking tons of questions and his specs and then just stealing his answers for the documentation. I'm a sucker for that approach, you do well now. I would actually suggest one of the other things that we sort of look at here is, for me, things will have abbreviations that we use. And getting them along with the terms is also super helpful. I also want to be really, really, really, really clear that some of the choices of abbreviations have evolved a little bit. So like, if you look at the very, very early decks, the network service manager was abbreviated in NSM, which turns out to have been a terrible idea. And then the one, the next episode of the KubeCon, I was calling it NSMD, because that's what the process was named. That turns out to be also less confusing, but has some confusion points. And I think Nikolai proposed abbreviating it, NSMGR, which I think is a better abbreviation. So don't feel bound by the, well, it's named this way in this deck. If we can come up with a better way, a clearer way of expressing things, that's awesome. Sure. And this goes back to the dot, zero, one release two, right? Is when you're definitely like going full bore releasing this out to the great blue yonder, we want a little bit of solidity around what things are so that way when people are asking questions or coming to the community and stuff, it's clear for them. But then, like you said, and then it's just as simple as if we're like this name or this acronym really sucks, then yeah, just in future releases, it's in the release notes. Hey, we changed the name of this because the last one was stupid, right? One of their quick, quick bit of housekeeping, I did want to mention. So I noticed a link going by where you're putting together a set of sort of meeting minutes and agenda that can be edited much like the ones we have for this meeting. That's epically awesome. I will try and get a patch into the website points to the box and points to those meeting minutes because I think that's helpful and important for people. And then you, it was one of the things that came to mind. I think that was the big one. The how do we find how do we find things like the meeting reliable? Yes. And actually, Nikolai, could you go back to the meeting notes real fast? Of course. So I added a couple more things. So like to that exact point, Ed, a docs repository. So right now, it's just a smattering of Google Docs that all of us have made in our own little private like Google accounts. And some of them get linked to the get page. Some of them don't. We should probably come up with some type of actual document repository that whether it's Google Docs, whether it's just things you're uploading, like a Google Drive folder or something where we are going to stash everything. And so that way, people can get you all of it. There actually is a Google Drive folder that I've been trying, not with 100% success, mind you, to put some of that stuff into you. So I'll link to that in the chat. And you'll see like a bunch of the collateral is there. There is a subdirectory for specifications. There's a subdirectory where collateral for the SM logo has been put so that folks can get that. So that that does exist there. If there's anybody can write access to be able to add files to that folder, please let me know. The folder permissions by default make everything that's put in that folder visible, but not necessarily world writable. I mean, for some things, you want world writability and for some things you don't, right? And I think probably Google Docs is an awesome place to marshal documentation because it makes it super easy to collaborate on documents. But as things actually settle out, we'll probably then want to transition them to mark down where they can go on the website or in the repo or whatever. And we just need to figure out where and how we want to put those things. You know, so that that becomes, you know, do we want it to be just a sub page on the network service page? Do we want to have a Docs done network service mesh.io URL? We've got a lot of options there. We just have to kind of figure out what works for us. Well, the most important thing I think if this is basically describing what code does and how the code is put together and how to talk about the code, then it wants to be in the main repository. And then where we choose to publish that after it's been checked into the main repository is just a matter of effectively release or build. That strikes me as a very likely outcome. But whatever ends up working for the community working on the Docs is probably the best. The reason I say that is because the problem with Google Docs long term, I'm not saying we would get the problem of keeping it separate, is that it gets edited by people who again are not reflecting the code. If there's a problem between the code and the Docs and they're in two different places, which one's wrong? Yeah, from my viewpoint, the Google Docs is a place to collaborate on trying to get the initial version of the Docs right. It's super good at that. It's actually not an archival medium for project documentation. Cool, and we don't have to solve that right now on this call. I just wanted to call it out that documentation is kind of scattered. This drive definitely helps. I'm not about recreating work that I don't have to. And then the final bullet is I'm just going to throw this question out there. For like the official documentation, do we want to come up with some kind of like consistency or is it just shooter's choice as we submit documents? And I put Lucidchart there as an example. It doesn't have to be. You can get a free account and you know open up files. It's kind of like Google Docs. It has a lot of the same challenges. That was just called out with Google Docs because anybody can go in and mess around with it. I mean you can deal with permissions but then that becomes a full-time job and self-managing it. But I just the idea of do we want like the imagery and the call flows and the you know diagrams and everything to look the same from document to document. And if so should we all pick a tool that everybody can access and decide to work from that? Or do we just kind of go our each way? I think in addition to this the point you're making about your common little conceal which is an important consideration. I think you also want to make sure that whatever imagery we have is something that somebody can come back and edit and revise easily. So one of the things I've tried to do for example is when I draw diagrams. I'm not suggesting this is the right way to diagram. It just happens to be the thing that I do. I'll go and draw them in Google Slides and then I will often provide some kind of a link from a sort of a PNG or a shift that I've done from the Google Slides that points back to where the originals are. So the next poor guy who comes by who needs to update that diagram can find where the original editable version is and edit it and regenerate images. Yeah and like I said if you're not a Photoshop master then you can also just like I said there are online tools that are just like actual modeling and flow diagram tools that we could all use and you can share the permissions and at some point you'll want to lock it down but you could like you know the equivalent of like an online Vizio or something right just so you're not trying to force some type of you know powerpoint type application to do stuff that it wasn't really intended to do. And to be super clear I don't personally have strong opinions as to what that tool should be. My strong opinions are about characteristics of that tool in terms of anybody can access it free. We can provide the ability to share and get to the originals for things that are being embedded in our pages. So the next guy who edits it can easily do that. Those are characteristics of a solution a particular choice of a solution I'm pretty agnostic about. I'm in full agreement the only thing I care about is some consistency between the documentation. I'm willing to sign up for that I'm not you know it's not something I personally value incredibly strongly but I do recognize it's intensely valuable for most humans who are reading docs and I value the ease of my reading humans quite a lot. Okay that's all I had Nikolai so but just so everyone knows I forgot the very first thing you asked me to talk about was the poll. So most of us wanted Thursday but most of the key players couldn't make Thursdays and so the next highest one was Wednesday morning 8 a.m. Pacific time and just for those who haven't been tracking it it's basically going to be document review calls so we'll cover like high-level architectural concepts definitions things like that with either Nikolai Edd or Frederick. We're going to capture all that information and then we're going to start trying to you know start turning out some of that documentation that Nikolai had listed for the release dot one. Great awesome thank you so much I appreciate it it's super important work. Of course okay so Ed do you want me to open the spec page or you want to share it yourself? I can go ahead and share if you don't mind. Yep here you are. Okay one second uh there we go yeah I'm not wanting to do necessarily a deep dive on any of these specs here in this call unless there are people who feel strongly that there's a spec they want to dive into in which case I think that's awesome. What I wanted to do was continue to draw attention to the kinds of things where the community is trying to work out specs for things so that we can sort of things often end up better when there's a there's the possibility of conversation around them and I do want to be really clear the specs process we have is not a gating process right you don't have to go and file a spec and write a spec and debate a spec in order to actually make a contribution at all that said you'll often you will often find that that the process is is helpful in putting together a contribution so if you feel it serves you please do and know that there's a good way to do that there's a board where we can add the cards we typically have been filing them as issues they those issues will typically link then to a google doc for collaboration and then once we settle we'll copy that into the issue so we get a record of what we think we're going to do the current stuff that we have right now we've got a couple around doc you know the nsc request documentation and high-level component document that Frederick put in that don't have associated issues yet I think that's going to roll into some of the documentation things we do have a spec that Daniel Bernier had started around SRV-6 for remote mechanisms so if you're interested in that that's probably a good one to go and comment on because I think I I can't begin to explain to the folks who are not networking people how amazing segment routing v6 is if you have IPv6 you should be using segment routing v6 that said it's just one of many things that network service mesh will support other specs that are sort of in process there's a spec that started up about sessions payload so think of this this way if I want to interpose like an envoy pod you want to make sure you get the right payload for that and if you look at the existing payloads we've had they've been things like ethernet or ip etc and none of those are really quite the right payload for scoop up all the tcp udp connections that are going out this interface and deliver them to a proxy port on a proxy and so the sessions payload type was an attempt to semantically specify what that payload what that kind of payload would look like because good semantics are super important and super helpful then we've got the spec that Nikolai's got underway for the NSM release process there's a spec that Frederick started for doing envoy as a network service which is part of what prompted the sessions payload type spec there's an ongoing conversation that Matthew Ruhn kicked off about metrics for monitoring cross-connects and monitor connections this has been kind of super interesting like where do we put them what makes us can we collect how we might we use them and then we've got a bunch of things sort of that's out there and and more or less in a good position but being reviewed like readiness probes which currently being worked on there's a really interesting one on creating a proxy NSM for doing create for those of you who've seen the talks and seen us talk about the create verb one of the things we came to realize is we don't actually need a create verb in the network service policy because you can do the create activity with a proxy NSM so it was a really good example of the network service mesh architecture getting simpler and more powerful at the same time we've almost actually got complete implementation now on the mutating admission controller which is super helpful but it's good to go take a look at that and we've got some really interesting discussions happening around inter-domain network service mesh how we handle crossing different domains and then also sort of as a shootout of that is an approach to having network service mesh deal with physical NICs including SRIOV and physical networks so particularly for folks just interested in NFE these are going to be super fascinating topics and under very active discussion so we actually have the readiness probes and liveness probes in kind of a more or less approved stage because they are being worked and we also the mutating admission controller right that's perfectly fine so this is goodness good hello so one thing that we need to do then is if they're in approved and are actively being worked on we should probably move them to the to markdown and stick them in the repo so that way that they're they're properly preserved yeah I think that's a super good idea because as we sort of put it out Google docs are a great way for to collaborate on this sort of thing they're great for things like meeting minutes that are kind of a running log but they're they're not a fantastic archival medium for specs so yes let's go with these things moved over into at least into the issues if not into the repo okay we can create a specs folder under docs and just you know yep that's probably a good plan awesome um what do you think I don't want to be really clear about like if if folks have things they would like to try and figure out specking the due to the mechanics of github if you want to add a card to this it requires a certain level of privilege this is not generally available so if you want to go file an issue that says spec colon and something and start up a conversation about how we might do a thing reach out to Nikolai or Frederick or myself we'd be delighted to add you to the specs board um to make sure that we can highlight this as we go by week to week cool that's I guess probably all for specs unless folks have questions or there are things people would like to deep dive into on the specs I guess that one thing that that we haven't agreed around specs is that when we declare them kind of approved it is there kind of timeout or I don't know some so at least not really formal procedure to to kind of say okay we all agree because there's no really the really the definition of all right yeah no the definition of all gets complicated and I tend to my general preference but frankly is to operate by consensus in all circumstances in which that's a workable method of figuring things out so I think you're actually probably had a really good a really good heuristic there which is when some would have converged to the point where we've got the implementation coming in we're really not talking at that point about debating the spec we're talking about reviewing the code and it's possible that in reviewing the code we discover that there's something about the spec that was so optimal that happens right but that might be a good way to do it and perhaps the thing we should probably do is approved as a bit of a strong word how would folks feel about you know changing the spec approved column to something like spec being implemented yeah I mean what's what's the criteria from something going from review to being implemented someone someone's writing code and pushing a PR even implemented though like I think like there's we might have a spec that we that we create but then no one in the no one's ready to take it on yet and may not be able to take it let's say for like six months because we all have things just from a time perspective you know and then it ends up sitting in this queue for taking up space for all that time so if we so if we end up so that's the one risk with with I expect being implemented is it may actually be a bit misleading we're actually implementing it yet or maybe someone creates a spec but we decided in the long run well we actually don't want to implement this thing you know so it's but it was still valuable to have that information and that discussion somewhere you know so we can still show it off somewhere so that's why I was thinking that the the end result of it would be mark down in the the code but not at not a serious implementation and then we can close the issue and then we can open up an issue to say someone please implement this and we can annotate the that spec is being unimplemented or waiting for someone to implement and so I I think that might that would give it a good balance okay we definitely sort of haven't refined that definitely um all right cool yeah and I'm and I'm not a I'm not a hard sticker on it if you know it's whatever works for the community that's the most important part so clearly you you Nikolai and I are ultra sticklers for process outcomes do matter at all process matters if we got you forgot to check off box number 43 I reject so Ed um I I feel like you're going to regret throwing this out there but you said maybe do a deep dive on one of the specs would you mind clicking on inner domain nsm since we have 14 minutes perfect I'm actually I just wanted to interject it with one quick comment about specs and implementation I think that the absolute most critical thing is that they're in sync not in the process itself but you know yeah well and I mean all of us who've written code realized that that sometimes you discover as you're going on but what seems like a super good idea when you were writing down what you thought you were going to do turns out to be a terrible terrible idea so there's there's back and forth there definitely but at the end of the day what would actually is in the repo and what we say is the specification of what should be in the repo if we're going to go put that in the repo those two should damn well match right so even if you have a spec and this is what we all thought we should do and you went and tried to do it it's not quite that you should go back and fix the spec that lands the repo so it matches reality okay cool so you wanted to talk about inter domain in a sum and yes and so real quick too just so that I'm 100% clear we're saying that a network service manager network service mesh manager everything underneath that is a quote unquote domain and then the next higher level construct is what you've got right on the screen right now which is the registry domain correct yeah so let me let me kind of talk through it because it's it's more of a for a recognition of things than anything else so the the the first recognition and this is trying to from the abstract architecture stuff I talked about with the deep dive is we have a network service registry right we have a place where network service endpoints register that they will provide services and so that they can you know something can go look those up and we're also we keep the network service records and the network service manager records that's basically a registry we happen to do that in the Kubernetes API server right now if you're ready to cluster the way that architecture is built it doesn't have to be that it just happens to be a convenient way we're stashing place we're stashing the data and has the nice benefit you can type to people get you know network service and get something and so in the abstract you do have a network service registry and you can sort of think of the network service registry domain for that network service registry is all the network services endpoints and managers that are registered with it and right now for us that's a single Kubernetes cluster in the way we implemented things but it doesn't have to be that it's much more flexible conceptually than that and this is often what I mean when I talk about domain is the domain of stuff that is being managed by a particular registry and please know a logical registry HA blah blah blah that is all stuff that happens so and then you you may have within that network service registry domain so a particular network service registry that may have a bunch of different network service managers registered with it and those network service managers may then be managing each a bunch of clients endpoints and possibly a data plane and this is very much like what we have currently in the Kubernetes example where we have a network service manager per node as a daemon set and so each network service manager manages the endpoints clients and the network service mesh data plane on that particular node but they all register with the same service registry which is scoped to the cluster which restoring things in the Kubernetes API server and this is a great focus for us for actually getting things done it's a really important way of doing it etc and so then we get to the question of inter domain and you can start thinking about this first is like what if I have more than one cluster right um how do I actually get services from one cluster to another um that sort of thing and so we talk about this like imagine that we have a Kubernetes cluster it has the traditional service registry as the API server every node has a network service manager etc and then I've got some other kind of domain with its own register network service registry and its own network service managers managing their own clients and their own day runs and this could be another cluster another Kubernetes cluster this other domain could be a physical network this other domain could be a VIM that's running a bunch of VMs that are providing network services um can we touch on that real quick the physical network or also like the concept of a VIM so like so I have this registry right and I'm just kind of curious like since right now it is somewhat coupled with like the Kubernetes API server like how is the demon getting put on all these nodes that would say be in a VMware or an open stack environment and then when you put it out there what is preventing NSM from competing you know or having state issues with say neutron or NSX no so this is so I'll get to the first one right the first one is it turns out when you look at network service mesh um what we have defined is a for in terms of the registry is a gRPC API and let me go ahead and actually pull the gRPC API off right now because it's going to make it super easier to talk about um so we have to find a gRPC API for registries and that gRPC API for the registries basically has a network service registry that has a register and I see let me find a little bigger that has a register NSC call and a remove NSC call right and it has a find network service call for doing discovery and this is this is actually the way network service mesh interacts with things like the network service registry so every network service manager this is the API that it's talking to talk to its network service registry now we have a tiny little container that exposes these APIs and then goes and stores the information and looks up the information of the Kubernetes API server but that's a literally that container is probably a hundred lines of go code and so none of the network service manager itself is not actually talking to the Kubernetes API server it's talking these gRPC APIs to that little tiny container that's getting us to that so if I wanted to have a different kind of registry that was going to go run in my Vim for some reason then all I have to do is expose these APIs directly and I am a network service registry so you have flexibility around how you choose to input registry for them or for the physical network because the real contract is these gRPC APIs does that make sense so far it doesn't so would say I hit these gRPC sorry I can't talk gRPC APIs and I make a request you know the other registry at that point it make an API call to Neutron as opposed to trying to directly program the data plane and the NSCs itself or like what does that interaction look like okay so keep in mind when you're talking to the registry all you're really saying to the registry is either hey I'm a network I have a network service endpoint or please remove a network service endpoint or you're saying find me a network service right those are the conversations you have with the registry so um in that you know registry doesn't actually do anything that provides you with information or store information for you so we have to walk a little further into the story to get to this point I think you're really curious about so could you give me a real quick second and we'll we'll get we get a little further down we can revisit this question so basically the you know basically so if I've got a Kubernetes cluster or some other domain and there's some other domain that I would like to get a network service from the current proposal is to say look previously you might have asked for secure internet connectivity and if you want it from the example.com domain ask for secure internet connectivity.example.com and then we will interpret the example.com portion as oh wait this comes from outside the domain of the current request right so at that point and I want a bunch of briefly that Nikolai has put it out this doesn't have to be welded to DNS and I agree with him but we'll talk about it for DNS because it's easy at that point DNS has a marvelous mechanism called SRV records and you could simply look up the SRV record for the network service registry for example.com and DNS you get back a port and a domain name so now you know as the network service manager in the first domain you now you know how to find the network service registry in the second domain which means you can use the find network service to your PC call to ask that network service registry hey man I've been told I someone wants secure internet connectivity got example.com you're the registry for that tell me about secure internet connectivity in your domain you'll get back the necessary information with all the endpoints and the network service managers and the policy and whatnot that you can decide which network service endpoint you think you want and you also know which network service manager in the other domain you should talk to if you want to set up a connection with them and so in that case you would use the same remote network service dot request that you use inside your domain for inter domain you would use to talk to a network service manager from a different domain and then effectively you end up negotiating the connection in exactly the same way you would for inter domain it just happens that the network service manager talking to is not in your domain at somewhere else and then the building out of the tunnel is also very much the same the network service manager in the other domain will you know plum on interface into the network service endpoint that he manages set up his into the tunnel the network service manager in your domain does the same thing and so effectively other than this one step where you realize oh we're going to a different domain I have to find the service registry for that domain other than that step the steps are pretty much the same as if you were dealing in the same domain does that make sense and so getting to your question that you asked Jeffrey about the the network service manager for them the network service manager for them would simply be a set of code that's specific to that VIM that if someone came in and said I would like to be connected to a network service gained neutron network 63 or whatever would know how to arrange for a tunnel that would connect you to that neutron network does that make sense it does this is definitely something I would like to dive deeper into with you for sure too because I think in the near term what you're going to see providers like my company do is we've already got a bunch of open stack out there we've got a bunch of VMware out there we're running virtual firewalls we're running virtual whatever but maybe all of my web app developers on the back end for like you know video experience x is all built in containers so having like our server farms hosting everything in Kubernetes being able to then create that bottom purple bar you've got there into the open stack world as that VPN gateway or as that firewall before it goes out great blue yonder I think it'll be important and I still it's kind of like nebulous like when you say like run some code you know like I mean am I deploying a container inside of every single open stack node and I just putting it in one place and acting as an API shim to call neutron on my behalf based on what like the network service I described further north is like those things are still kind of giving me a brain crinkles so I'm I'm going to actively start looking at at open stack integration as an example to open stack through vm apps and then back again so because it's something that I want to try to demo out so perhaps what I can do is come up with a spec like we have there and we can go over it and you can help that would be great yeah I do apologize I have got to run to another call really quickly here but this is a super interesting conversation I definitely want to continue so I we don't need to wrap it whole I'm just curious like you gave me the opportunity to say we could deep dive on a spec so I was greedy no no no it's a super good topic I'm glad we had the discussion I just have to run through another meeting so till there so um Fred yeah this would definitely be interesting to be put in a spec where we can collaborate and discuss about all these things because at least up till now the specs seem to be the the best way to exchange the information there and then everyone can you know just process it through his own lens and express his opinion okay I guess that that we should wrap up the call with this we are on top of the on top of the hour already so if if we don't have anything else to to discuss yes we can close nope see you the same time tomorrow Nikolai for the document call of course awesome appreciate you thank you bye guys see you next time bye bye bye