 So we vote why is the zoom in? Oh it's zooming in everything, but the thing I wanted to zoom in This is gonna need to make it into that This guy Yeah, I just wanted to to discuss that that's why I kind of Spent last half an hour trying to figure this out kind of gather my thoughts But my idea is that I would like to change the Messaging NSM in terms of I mean, I'm not saying that this is that I just try to gather my thoughts I'm not saying that this is the right thing But I would like to start with the fact that we are changing the definition of a service I think that this is the core thing about NSM Not not that it's a new way to implement the V etc. Etc. This is kind of consequence. I think I I'm 100% with you with one mining minor change, which is I wouldn't Definition of the service because that starts raising antibodies around folks who are concerned that we're trying to Change all things in Kubernetes Yeah, I don't think it's that I think what we're really talking about is pointing out that there is another There's a different kind of service and yeah, and that that's really what we're talking about and that it gets okay It has a flick ability in all kinds of places and I'd love to start with the The enterprise stuff mostly because and I think I've said this before If you show an enterprise use case to a service provider, they get it If you show a service provider use case to an enterprise, they have no idea what's going on Yeah, yeah, um, does that does that sound reasonable to you Jeffrey is the you the service provider in the room? Um Yes, I thought about 80% as far as reading stuff to the only I mean, yeah, I agree We don't want to attack people's concepts of what a network services or what applications people think of as a kubernetes service This does seem very kubernetes centric though for the whole what is an SM and No, I feel like every Indian actually, maybe I mean I just added in the end the couple of It is approached to various domains right at the end here. I mean unless you're talking about a different but I mean like An existing solution like I mean Telco like It seems like yeah, here's these domains, but like we're gonna address these said domains with kubernetes like Yeah, I mean I've it's just some random thoughts. I'm not saying that I mean the core of it is I know I Would like to start from the fact that there is a network service and it's a different approach as I had said It's not changing the definition of a service, but it's a different approach to defining services. Okay, and that's Important thing everything else is just Don't worry, I think everything you have in here is gold Wait, I mean we make some tweets, but I mean it's just it is something I've noticed in general is we say Oh, this is a holistic thing, but I'm we're only gonna talk about kubernetes now for the next 90% of the what-have-you or VPP is only one data plane, but we're gonna only talk about VPP like I really feel like in our messaging and when I mean we're audience to CNTF so like We we can take a little bit more liberty like we really just need to start talking about the fact that NSM itself is the distributed mesh that gives us network services and then Like always start with the whole cloud native networking Conversation first and then bring in the kubernetes because kubernetes is one way that you make You know orchestration in a cloud native, you know possible, but like I mean like right out the bait It's just in kubernetes boom boom boom like we're literally like right off the gate saying like here's how kubernetes does networking Here's how we do networking versus here is a cloud native approach to networking and by the way We can do this in kubernetes without you breaking everything I I think in the definition we should leave kubernetes out entirely and then we can talk about kubernetes integration in a in a different area Yes, like that. That's my exact that like I think in what is in SM. We should just say this is what NSM is not with Kubernetes caveats and gotchas and you know, we're not gonna like break things just here's this really awesome distributed mesh It does really cool things for you and in the different implementation sections One of the really cool things it does for you is it fixes the plumbing and pod namespaces I don't know Ed. Nikolai. I mean if you think that we're completely off just I Am I'm always open to having my opinion change which makes me unicorn in America, but yeah I know it's a statement I make every time someone asked me about opinions about bagging groceries where I point out But I try not have strong opinions about things that I don't understand which is So but anyway, the um, I think this is all going in a big direction So my my input is primarily just structural not content at this point because everything you guys are saying from a content direction It's actually quite good My structural input would be that we want to as we're breaking down the message We want to make sure we have a super simple sort of elevator pitch of that that we can lead with front and center at The very beginning of the opening page something that will grab people and really draw the drill drill the notion in And then we can look at adding stuff. That's a little bit longer form Does that make sense? Yep And I said I mean from the content perspective. I just Either you know go one way or the other but like we got to decide do we always come at it from the context of Hey, we're really good at Kubernetes and by the way we can do all this other stuff Or here's this standalone really cool cloud native solution and we kick-ass at integration with Kubernetes What about We're committed to the cloud native language and we don't have to say Kubernetes specifically but The cloud native side you're gonna have CI CD There's gonna be some possibly some discussing about containers that might be contentious There's definitely gonna be an orchestrator everything that's in the cloud native path towards maturity and then you don't have to say Kubernetes because maybe another orchestrator will make its way in Like this especially since like one of the things I often will be the drums on is three very central tenants of cloud native which are immutable infrastructure loosely coupled and minimal toil and the the fact I think sort of those are good places to focus because They can apply all over the place. It's not just Kubernetes, but they're really the things that everyone is looking for I Just um, I feel like I'm constantly explaining to people that we do more than just Kubernetes and we do more than just VPP Oh, yes. No, no, no, I mean that you heard the question on the TOC where Quinton gets like Mumble-mumble-mumble, but wouldn't you want to do this of their places? It was like, ah, yes. Yes, we do So Yeah, I think that this should be the very first slide of this and that ultimately we need to bring in this to This also Frederick you merged and this is it's now a draft in Yeah, but it didn't it didn't hide it so just you know, I don't know why I mean I I noticed that I need to work out why it's not hiding itself There's yeah, I think it's something that Something in the get tooling because I did my PR as a draft Yeah, what one thing by the way we can do when we go and Are reviewing these things is there is a link that's generated by the CI for the site That will take you to a deployed version of the page And you can always go look and see what actually showed what's going to show up when deployed So Yes, so obviously I'm Frederick you and I should take a peek at that. I'm also putting this into a document which Let me move it to the thing so that we can but it's still relevant from this guy and Added to this Because I one of the things I liked about the original in the same as it does have all the little diagrams with you Know this net like talking about the different Requests and accepts and you know calling services by name, etc. Which um that stuff needs to continue forward I Think for just the definitions document though We take you know kind of like what Nikolai has here and massage it a little bit and just have that be the opening thing Really quick. Let me just kind of go to the agenda So we do have some stuff that we definitely need for Andromeda and I think some of this we can probably start Now that everybody knows because we did the glossary kind of like what the actual components are like We've all kind of come to agreements on what common definitions are. I think we could also kind of maybe get volunteers and Delegate a little of this workout and then have a big portion of this call be more just Peer review versus us going line by line and debating what every definition is like now that the definition is set Like we assigned someone to write a quick install guide. They bring it to the group We all you know give our candid feedback get it to a good spot and then we put it in get I don't what do you guys thoughts on that? Sounds great to me. I mean the more we can sort of get this turning nicely You know out of sight of live calls. I think the more velocity we're going to get Right because it usually is like One of the four of us writing thing down on that document and then arguing about a single term for about 45 minutes And I think like you were saying it will get a lot more done if there's like 20 people writing things And then we're just arguing about lots of things for like 10 minutes at a time Are you saying one person writing that's scalable I've never been able to recreate Michael Keaton's multiplicity scenario, so I just I'm nickel. I'm throwing you into the bus here. I don't think anybody's gonna understand the SDK quite like you since you wrote it Yeah, I'm yeah, I'm updating the docs now I mean a process of yeah, so okay These Maybe next week, you know with the and to be honest the documentation call Sometimes we get a ground swell of people coming in at 30 after the hour just because of conflicting calls and stuff but maybe I'm Ed if or Frederick next week in the main call on Tuesday, would you guys mind potentially putting out like a call for volunteers? Because we have people who like email me and they're on like the boards that are actually Semi-active in the documentation effort, but they don't necessarily attend our call, but I'm I think I'm happy to put out the call the other thing I would suggest is Lucina has kindly volunteered to handle social media So you might want her and see if maybe putting out a call on Twitter and such is going to be helpful Sure. Yeah, also make sure you add it to the agenda Add Lucina to the agenda No, I'm at the calls for help Yeah Gotcha Now getting on the agenda is super simple It's great squiggles something in the embrace something in the agenda and odds are we will talk about it and I'll add that We know that the site needs some love Just holistically, which it sounds like we can get CNCF to help us I will work with Nikolai on This figuring out what we can salvage like you said Everything in here is great. Nikolai. I don't want you to think like we're coming after you on this Completely understand. This is just right written. I just started to the end. I never looked back So I'm not even sure what is written in the beginning Makes sense And so the glossary I mean until people start making pull requests We're in a pretty good spot on just like the pure text definitions Nikolai's got it merged into The main get in the read me section or sorry the doc section. So now To remove as much ambiguity as possible I've been working more and more on this guy stealing images from some of ed decks things like that I've actually been breaking things down into more granular slides Mechanisms ended up seeming like they needed their own slide versus trying to wrap it into like wires and connections So I kind of want to just For this call It is something I want to like discuss live because I need kind of help Which are guys' thoughts are as far as like images and diagrams because I'm just kind of shooting from the hip here So like the network service manager, I don't there's not a ton like visually I can think of to do it just I want to somehow clean this up so that it's a little bit more transparent that this is a node level entity or like a physical device so I might actually collapse some of the detail in this and Kind of bring these individual components in a more collapsed fashion just showing how like an ensm Fits, you know in the whole network service manager context I like very much how the direction these things are going I would I would like to once more point out that I I'm actively trying to remove the nsc and nsc from everywhere that I I'm touching. I'm just saying Terminology is viral like that. Um, yes We're trying to remove nsc and nsc Yes, I mean, I'm not sure that everyone agrees but I mean, I'm just pointing out that I don't like this I You don't like the acronym or you don't like The acronym itself service endpoint. No, no, the the acronym because it's Uh, I take no offense to the fact that that nicolai doesn't like the acronym. It's probably not a great acronym Um, you know, it was the happenstance to organic terminology Well, let me ask this. Do we even need an acronym for this or do we just want to call things clients and endpoints? That's what I do Yeah, I think that Nicolai is trying to move things in and I am super pleased with that direction So long as it is used in the context where it's clear. We're talking about network services. Yes Outside of that context, then it gets super confusing because clients and endpoints get used a lot Yeah As well as service and you know all these Overloaded terms Yeah um, and so We might even want to um, nicolai on git let's either you or I today put in a pr and Let's just remove nsc and nsc from the glossary definitions, right? um because If it's right there in main git and people are reading through the glossary and they see that it's going to stick From them point on right like they're gonna They're literally going to look back and say well, you guys literally have this in the definition This is the acronym for it. So yeah, just let's um, let's nuke those get rid of the little follow-on parentheses. Um So I do have a couple questions on certain things. Um, so yeah, I think I'm going to remove This doesn't need to be quite as big or granular and I want to show network service manager in different contexts. Um So external network service manager. Does this diagram pseudo make sense to people? Um it was a very Like just like I said from the hip attempt and I I feel like I don't know It makes so the It makes sense to me, but it's a little over detailed on the open stack side. So it's a great ENSM external and the server service manager in the context of open stack diagram But we probably need another one that's a little more abstract Yeah, also the only the only major complaint I have in the details is the ensm Um talks to the gate lay and then you show the gateway talking to the other ensm But the gateway Would probably only talk to one to one no no so and this is something I'm I'm trying to figure out So if you see it's hidden underneath the gateway is talking to open stack, which ensm is manipulating right I just need to figure out a better way to do this this this guy is actually Oh, okay. I get it I don't I need to like and you know, this is fully edible too. It's not going to hurt my feelings that people come in here and just completely change things I know I I get it. I it looked like the Yeah, and I knew that was a deficiency We just we just have a lack of dimensions. Yeah, Jeff also, you know The the ensm is probably not just open stack specific, right? So I'm sorry, right So check it out. Here's this ensm is talking to this ensm talking to this ensm, but this is um, and really all of these need to be This they need their gr. So this is physical network, right? Completely and wholly isolated from the open stack networking What that's only an sm it makes it appear in the mesh to these other ones, but um, like You know, and this could be slash V or V or V sphere, whatever Right, like it doesn't it doesn't have to be just open stack. I'm just sure here's a domain that opens stack controls Here is a physical domain. Here is a kubernetes node. Um, and here is all the different peers in the mesh and It's making the translations in the ensm case talking to open stack here And this is you you saying that like proves my point that this needs to be massaged a little bit because if you can't just Look at it and know what I was trying to convey then obviously my pictures are not up to snuff yet But um, this is good feedback, right? But what I'm trying to show here is you have your kate's api server, right? And I'm already breaking my own rule because now I'm making the assumption that kates is involved, but whatever um But I have this node here's your typical network service manager running in the pod namespace kind of manner Here is a vim and you know, that's actually I'm just going to change that for now right there just So that we 100% know that like this isn't tied to any specific vim, but Network service manager is tied into the mesh and it's talking to the vim the vim programs its gateway based on the requests and Acknowledgements that it's made through network service manager. You have a physical domain doing the same thing. This is, you know, just like an alu or you know asr or whatever some type of router. Thank you, nicolai And I'm trying to show different domains quick suggestion Jeff The gateway that we show here it's its role is purely data plane, right? If we can move that guy below Basically, you know try to put all the data plane components on let's say the Row one below row and then you put all the NSM components on at the high level, you know on a top row. Yeah like that, you know, then you know It'll be clearer, you know the data plane Could be across disparate environments But what we're trying to do is we're trying to stitch up the innocent components Excuse me Yeah we think to show like some of the vim plumbing is is it worth it showing the concept of a tenant in an external network to show the different networks within the vim being plumbed via an external service manager Okay, that's not great, but Well, and we can massage it so and actually let's just um And right now I just really want to capture your your all thoughts more than anything. Um I'm not touching it Data plan No, you can continue to edit, but I just want to make sure like We um, we capture any thoughts that don't get fixed right this second. Um Yeah, I think this gets around to the thing I was saying earlier about um This may be a good diagram for describing a particular case with open stack But it's it's trying to put too many things in one place And my tendency and admittedly some of this is driven by my own mental prejudices would be to start with a very abstract sense of this and then give concrete examples that would start out with a very specific connect to Something that's provided by a vim. How do we connect to something provided by a physical net? I think you might be able to show how you can chain them together here as a last step in building out those examples Yeah, I Trying to keep it succinct. I was falling into the trap of trying to get like the big blocks of text and these comprehensive diagrams on one but Really what probably needs to happen is this needs to be pulled down so that there's way more space to work with There needs to be the abstract diagram on this page It doesn't we like just like node vim physical and nothing else Don't try to show any of the routing this and that just show enus and managers just sitting around And then the next one we can drop down and actually get into some more of the granular plumbing Um, because yeah, it's just trying to squeeze way too much into too small of a space here You could also show a very simple use case but And this and break them apart. So You know Kubernetes manager to an open stack base manager Kubernetes to physical Open stack to physical as independent as independent things and then show something where they get chained together as well and then and then we can drive down into And that will should all fit into one slide and then from there we give a drive to Here's what uh, here's what the chain would look like now that we've given it some some context And then we could probably find a way to reuse this slide Yeah The big thing I definitely want though is for someone to just be able to very quickly conceptualize that like network service managers Can live outside of you know kubernetes on its own and that it can Give you a declarative model for like multiple network domains and span a network service across them Yeah, so if I can make a suggestion, um, maybe one of the ways to do this is rather than trying to build a Chain like this would just be to show the side-by-side side examples Um, because if you just show a side-by-side example where you're connecting to Um, a vim in an open stack, that's a super good example And if you show us an example where you're connecting to a physical network, that's a good example I think where it becomes more confusing is when you try and chain them together. Does that make sense? Yeah What it comes down to is one of the things I try to do and I don't think successfully But I try is to limit the number of concepts in any given image that I'm showing people concepts Whatever they're looking at there's a very small number of new things throughout their head around Yeah, well, I originally tried to use the one of the use case document, um, like images and There was like literally 80,000 things in a single image and I was just like oh my god I was trying to boil that down, but failed any miserably Well, you're absolutely right because these cases presume a lot of stuff, right? Not only do they presume a lot of knowledge about NSM, but they presume a lot of knowledge about the underlying use case Um, and and most people have a limited Limited capacity for new cognitive load Um, and so you sort of aim with that um Do we need a diagram for a proxy network service manager? And if yes, I don't like I need someone to like give me some thoughts on how you Diagram something as abstract as saying all of this is the same But like there could be more steps that come in afterwards It's almost more like a flow chart versus a network diagram or an application diagram Yeah, and I presume you've already looked at the existing proxy network service much diagrams I didn't quite give you what you needed, correct? Um, I don't know maybe I was looking through all the different specs all the different, um things just trying to like If you've got it, maybe I didn't look at the right diagrams Well, no or it's entirely possible I'll send you some links to what I've got it doesn't mean that they're the right diagram You're looking for it just means that things to go take a look at Because again, that's actually one of the weaker sets of diagrams that I've done And also it comes from like those very strange perspective that lives in my brain, which is not like other people's brands Like if you if you look at like to the definition here, too Like do I just take like say we simplify this diagram? Do I just put like another like slightly different color box here and like put like right logic here? I mean Yeah, let me let me like I let me find you real quick. I'll link to one of those Diagrams Yeah It's somewhere a diagram of a proxy networks manager where it was sitting in the middle And on the right there were a couple of other NS managers, which it was proxying for Yep. Yep. Exactly. Let me yeah, okay And and just uh, just since we're talking about color just be careful not to convey semantic meaning with the color because um Or to be the only the only source because we we may we will have people who are colorblind Yeah, I've made the disclaimer multiple times that I have no artistic ability I literally just kept on this weird alternating color scheme because that was what was in a lot of the other slide decks And I was just trying to keep things consistent. I know it's again. I have color It's just make sure that it's that there's other things conveying as well Nothing but reds and greens Exactly Yeah, one of the things that I've actually asked the aesthetics about is If you can keep in the back of her mind Because god help us. Um, I have produced the color palace to date and you all see how that ends So This like with everything else is sort of a build up you would maybe want to collapse some of this but it sort of talks I've been looking at it so far the new the new logo is um, Left around devices is red with flashing yellow. It's animated We revive the blink tag Because if you you know, so you've got things like this and if you go further down in that that link I sent you there are other diagrams that build out more of the picture Um as well, and so you can sort of decide which one you want to terminate with Yeah, I'll just throw that guy in there because now that you taught me the cool way to right click on things and go to its source I can always get back to this guy now Yes, isn't it wonderful. Um Did michael gourman make this slide deck? What's up with the lightsaber? Oh, no, no, no, this is not an agormon slide deck That's all me I am not nearly as skilled as agormon This this was based on the conversation we had at the open source summit in vancouver And we came up with the idea of a P of the Pnsm and I think too dangerous to uh to wield for most use cases So I think most people are going to get themselves in trouble with the pns and Yeah, also we sorry. So lightsabers are equivalent of uh warning. Here be here be dragons. Yeah The really cool thing about the proxy network service managers are they are amazingly interesting and useful tools They will let you do all kinds of full stuff like, um, you know, basically the the create verb kinds of stuff and a whole bunch of other awesome things unfortunately Almost every really terrible idea that you might have from a classical sdn way of thinking can be done with a pnsm so What is smart and what is dumb is going to be super interesting Okay. Yeah, um Yeah, and the worst part about it is it's not going to be apparent for on many cases as to what's smarter dumb But we'll learn with time Yeah, there's going to be some pretty epic catastrophic failures. I think and i'm looking forward to Immortalizing them and reminding people of them as we get older That is why we have the lightsaber right because the the thing with the the pnsms is they are like lightsabers They can cut through anything. We're not strong in the force. You're going to cut your damn arm off You never know there might be that one Mandalorian that just shows up in wows or so I don't need your gyroscopic whatever thing inside the hilt. I'm just going to brute force this because I'm a bad ass exactly Okay, so Moving on and like I said, I'm I kind of just because this is like the first pass I want to try to get through majority of the slides and then we can continue to refine them like we did with the main glossary but um service components Um Goodbye evil acronym Okay, this is pretty cut and dry Carries packets so local and remote mechanisms, um, I Duplicated this because we have the concept of a wire and a connection um, and obviously the remote mechanism Plays way more into that wire slash connection type thing Did this make sense? And I probably need to add a local mechanism also point over here to vhost user and memf Just you know that every single one of these is an example of that But then we have the vx, you know and caps the excellent encapsulation going across the wire showing, you know The mechanism that is binding these two points Yeah, no, I I like where you're going with this quite a lot actually because it is one of the things that One of the things that people really seem to get their their heads screwed up on is they're like But but but how does the client? um How does the client tell me that you know what vx land vn idios and the answer is it doesn't And that seems super confusing to people at first That you wouldn't make all the responsibility for all the thinking in all the world the responsibility of the client or the endpoint Yeah, something else that I've noticed as well as when people who are familiar with vx lamb We say oh, well, you're going to reuse the anise wait. That's that's not a good idea And explaining to them the three tuple that we can use rather than the one tuple Well, this was actually something that I was screwing up really early on because I was like assuming Way too much responsibility on like the endpoints and network service mesh in it in general it's like no, no, no, I just need to Put this, you know encapsulation on here and stick it in the right vini, right? Like there's all of this other networking that already exists or even a better example is like, you know Like an mpls or a segment routing example, right? Is I don't need to pull every single Like device I have in existence into the one mesh, right? I just need to do some cool cloudy things in a isolated environment and then just say Okay, once you're heading out into the like, you know, once you hit this p router You've already got your label like I'm just going to let vgp do its thing or s r do its thing, right? And that was like a hard concept for me to get eventually or originally. So I've been trying to Save people from my pitfalls and my flawed logic Well Yeah, exactly and the locality of it all actually ends up being super convenient Like I'm still unbelievably proud of the trick that we use for vini assignment. I don't know if I've mentioned this to you guys before um Because the way we do vini assignment It is you don't want to have some central vini assignment place you have to consult to get issued your vini's. That's terrible um, and so the trick is Every incoming request for a vini has a source ip and a desk ip Um, you know, it basically has a source ip and you know your desk ip because you're the guy who's it's going to and literally if source it If source ip is bigger than desk ip literally as a straight up comparison Then you're assigning from the odd pool. Otherwise you're assigning from the even pool and so Literally, we've split the vini pools of the odd and even connection by connection Depending on the the card now the ordinality of the ip's it The uniqueness of the vini when you assign it in that approach is good however, when different Vxlan endpoints start talking to each other At time t1 you might be good at time t2 as the vxlan endpoints talk to let's say a more number of endpoints The overall vini's that are used for a single broadcast domain We have no broadcast domain everything is a point to point wire Sure, sure. Let's say I call that as a service tag, you know Yeah, but but so we're negotiating these point these point to point uh connections It's not the vini that determines which connection you're on. It's the tuple of source ip desk ip and vini Yeah, i'm talking about the service ed not the actual connection The identification of the service Will it be a single vini across or will it be looks like you're driving towards a model where it is unique only between the tuple Yeah, because everything is a point-to-point connection in a network service mesh everything so It's always going to be a point-to-point connection Um for that now if you have a payload That's that's got a vini in it. I don't know and care what you're doing there, right? That's up to you But if we're talking about how do we get It's from the client to the endpoint and there happens to be a vx land hop in there That and hop is you know uniquely defined by that three tuple Point-to-point and so we can successfully assign those Yeah, what i'm struggling at is The connection is surely too tuple. I agree with that, but the vini as a service That is that can span across multiple connections, right? Well, tell me what you mean by a vini as a service because I don't quite understand that Let's say, uh, well, uh, i'm coming from the pure core networking site. So let's say I treat that as a layer three vpn Obviously it'll span across multiple endpoints Okay, so what you're saying is if i'm using a vini in a classic broadcast sentence, right? um on my network then what right because if i've got a vini and You know, i'm you know, i've decided that i'm going to use that vini To connect a bunch of things for in a virtual bridge domain because that's all you can do with a vini is connect virtual bridge domains Or even or even l3 domains, you know meaning The vini is vx land definitionally carries ethernet frames True true, uh, but you know you know about the layer three vini's right Where you're basically Definitely, sorry, I know about the xlm gpe and you could of course decide to interpret that You can decide to interpret that however you'd like that ethernet frame But no, no, I'm not talking about the frame Ed the vini itself it can represent As a layer two vpn or a layer three vpn, you know when you use it as a layer three vini meaning It's never used in isolation It's literally physically impossible with a vx land protocol to use a vini in isolation correct? Yeah It's it's a it's a fabric wide Um service or a network wide service. No, no, no go to the protocol always go to the protocol if you look at the protocol literally There is no concept of a vini in isolation from its source and desktips the idea doesn't exist Now you can decide that that a group of source and desktips are going to interpret a vini Commonly as a domain among them But that is a decision among a number of ip's to apply an interpretation to that vini Any ip's that are not part of that group are not bound to provide a particular interpretation to that vini Yeah, I think we are seeing the same end Exactly so there is there is a potential here If you have decided that your nodes are going to be participants in something with a vini Has an underlying meaning you do have a potential for conflict But so far that doesn't seem to happen very much and if it does it can be you know If that does end up happening then one of the other of them can essentially exclude a particular vini in order to avoid that but Part of what I the point I'm making is I actually think that we're going to discover over time That the abuse of vini is as global Sort of concepts like this turns out to be an anti pattern um But anyway, the underlying point I make I guess I'm making is that the only place I think that's just the potential to be problematic is if you have Use vx the anti-sphere bridge join a bunch across a bunch of nodes And the nodes are also participating as with the same ip as things that terminate um l2l3 connections then think potentially there's a problem But it's a great question Yeah, I think ed it'll be good if we don't exclude Centralized assignment of you. I think we should prefer the distributor the the one that you're prescribing Uh, it's just that for the cases for the unknown cases or the scenarios that we haven't thought of But that may be and we could definitely look at that But it should be understood that centralized ipam and centralized vini and all these centralized resource mechanisms I have to be deep anti pattern. They don't scale for shit. They're hugely problematic They're extremely expensive opx wise to manage and so anything you can do the lesson of cloud native Anything you can do to minimize the centralized decision-making and control is a win Yeah Yeah, no disagreements. They read, you know, uh, I'm just worrying about the traditional networking scenarios and No, I understand but again the traditional networking scenarios also are very limited in their scope because If I have a let's say I've got an underlay network that has a bunch of switches and routers And some switches and routers that are collaborating together that have decided that they are going to treat a vini as an l3 Or an l2 domain, right? um As long as I am not actually trying to use any of those switches and routers as source or desk IDs In a network service mesh the fact that I happen to be using exactly the same vini between a source and desk someplace else is absolutely harmless Yeah, absolutely No disagreements there. Yeah But it's a super good question and it kind of gets to the point that I think was being made earlier Um by fredrick, which is one of the things that really screws with people's brains at first is they're used to thinking of vini as these global domain things Wouldn't in fact that's literally not what's going on in the protocol and it's not how we use them Yeah, it's so is it just a local label in this architecture? Exactly. It's exactly a local label here. Okay You know it did so when we get a connection coming in Um, and it's one of many many things that could be used as a local label Um, when we get a connection coming in we could use a vxl and vini to tell us which connection it is We could use um, you know srv6 sids if we wanted to We've got all kinds of things that let us demux the stuff that's coming into the ip So it is just used as a local label to demux things Yeah, so this is a big benefit we get when we move away from the Neutron style rigid domain as your primitive that you attach ports to and you move towards the local To the wires and connections as your Or rather the wire as your primitive. So the local mechanism and remote mechanisms that you compose together um It allows you to It allows you to gain a little bit more flexibility in this specific in this specific use case Yeah, and jeff we probably need to Run this local label notion against ENSM scenarios right where ensm is managing let's say The open stack deployment or some physical network which kind of treats vini as a Oh, there's one of the things here that's actually super helpful for you actually And that is that the the entity that decides what the vini is is the network is the endpoint Does that make sense? Yeah. Yeah, so in the so in the ensm case it could be the Non-nsm entity that is deciding the label Exactly. So if I have a router that is using a vini for something Um, then it could go ahead and say okay. I'm using this vini for something else. So I won't use it for um for responding to a client and That that's actually so that goes back to my original like point though, right at that I was making where my confusion was is The ensm example is a prime example of where if I have this physical router And this is exactly what I was just saying, but this is the part that was tripping me up fanny is um Like the router knows what its capabilities are right and it's going to make that available through the external network service manager and If it is the final endpoint then it is going to pick, you know, it's the excellent schema You know, it's it's already peered with a route reflector It knows in its tables what vini's are and aren't consumed It knows how to get you know, whether you're asymmetric or symmetric routing It knows all of this right and it's just going to say I have this And then once it provides that connection the point-to-point And you know, we'll call it like the east side once it starts heading west It's now just traditional networking, right? Like it's going to the route reflector and saying, you know, how do I get to my next location? Please put it in this vini and away it goes and like network service manager doesn't care about any of that Correct. It doesn't care. It only cares about the entry point where basically the gateway And what what what vini's The gateway would like to advertise towards nsm side, right? Yep Yeah, and if the thing you're connecting to happens to be something that is Let's just say in this scenario, it's neutron and the neutron implementation you're using requires a specific vini for a for a specific entry point then The and the ensm can Provide that vini so that way that all the clients coming in End up connecting to it So there is something we don't have to be a bit careful with that scenario though Which is on the point-to-point where what happens if you assign the same vini on the from an ensm Then and you're connecting something that scuba net he's related a pod Let's say it's a pod then we do have to be careful to make sure that we don't Because at that point then then we can have a conflict. So so we do need to be Careful with with that scenario So going down one more we're going up one layer up an abstraction wires and connections so Does this make sense from a diagram perspective got a wire between here and here got a wire between here and here The end to end data flow is here because if what I want is a connection These are all the components in the middle one thing I would suggest about this And I'm not sure the best way to sort this out is that purple line on the bottom could be interpreted as a Some kind of a bus or a bridge domain Because it does sort of look like these are coming in maybe making the goes ins and goes out So on those two intermediate nse's clearer might be wait say that again. I missed it. I'm sorry Okay, so make right now if you look at the second the first nse the first end point as you go from left to right So you got a client. Yeah, it only has one thing going into it And there's actually two things going into it. There's something coming in from the incoming Wire and there's something going out for the direct MMI of Does that make sense And the fact that we're only showing the one might confuse people about there being some kind of a multi-point thing going on along that purple line I think I get what you're saying. I'm I'm not visualizing it in my head. So if you just want to hack the image Um, I mean, uh, conceptually I understand what you're saying. I just don't know how to visualize it and well, I mean There's an interesting mechanical problem about how to change it cleanly because multiple lines that do a circle is hard um But but the the underlying thing I would get at right now because we are running short on time It's just conceptually that you understand why this might look like a traditional l2 domain being represented by that that purple line at the bottom Mm-hmm. Yep So cool that that's the only point I would make there and we can figure out how to sort out the picture as we go Yeah, but you make a good point once again if you have questions on it then other people will just make the assumption that it's a l2 domain Yeah, and then one last thing real quick. So we can take a peek at the data plane here This one's been around for a while. Um, we can continue to tweak it, but control plane How are we gonna So we at least have a a definition for control plane now from an nsm since How do we want to draw this? Okay, so uh When we're talking control plane and then we put it just after all this these other pictures of External that because essentially the control plane is composed of all the network service managers Yes, I mean this should be definitely be Way up in the stack before we talk about external etc I mean It's an interesting thing because it takes a concept that we are very familiar with in You know, we are familiar with control planes in networking. It's kind of how we do everything that actually works But we sort of as an industry took this this detour through sdi and We're suddenly control plane met a big brain in the sky and definitely that's not what we're doing here The other thing, uh, nicolai with the ordering and I just I need all of you to weigh in and kind of help me pick the lesser of you know All evils not just two Because the biggest problem with a lot of this is You know, I make google docs Is we constantly use terms To build definitions that Have to have their own definition and so It's I've been trying to figure out like ordering for that, right? So like What's that circle dependency Circle the dependency circular dependence Yeah, oh circular to be exactly right like we we're we're using the definitions of things and the definition of things And so like then when I order i'm like, I can't put the control plane Before network service managers or I could and I say, you know reference this slide Like maybe I do a little asterisks and do a little footnotes, but that circular dependency keeps biting me every time I try to like order this it's it's been An interesting challenge Right. Yeah, yeah, yeah, I agree Yeah, okay, I'm not muted. Yeah, I agree because I'm I'm with you logically the control plane is what programs all of these things right In a cool decentralized manner but I can't like use the definition of the control plane until I actually tell you what all the things that's controlling are or you're just like What do you mean? Let me let me give you a potential solution for your circular dependency The way I would say this is Think of it this way. You are not actually defining what a control plane is Right. That's a pre-existing notion in most people's minds What you're doing is you're taking the definitions you've made of network service managers and network service We're taking the pre-existing notion of a control plane And you're using them together to provide the scoped meaning of control plane in this context Does that make sense one on 100 percent? Yeah, it's sort of like if I were if all I knew in life was rip, but I had an ocean of a control plane for rip, right? Um, but you know and you said okay Well, we know what control planes are and I'm going to go introduce you to ISIS and I go teach you about ISIS And then I point out that ISIS is actually a control plane in this this in this concept in this scope Right that that works. So that's I think how you linearize it in your own mind We're not defining control plane. We're we're scoping control plane to this domain No, I agree like Because we're scoping it though like a lot of like The the lens of what we're saying the control plane is in this implementation really because I mean that's what we're doing Right, we're giving a definition for this implementation of a control plane to your analogy is um, it just gets a little bit hairy sometimes So like I put domains at the end just because And it feels super awkward like it's just like tagged on there at the end and it definitely doesn't We need to figure a better way, but like And when I talk about a network service manager domain, it makes zero sense if you don't know what a network service manager is um But you can take a network service manager get its definition without possibly needing 15 other dependencies and so I don't know. I think maybe we just put them out there and then we just say, you know Reference this like because it makes like no sense to me like Flow wise to have domains here at the very end, but I just it was so dependent on all these other Terms like I don't know the clean way to solve this Yeah, that's actually completely fair So I am like let's just noodle on that for a bit. I am open to suggestions like maybe we You know use like Do we just point to things maybe we make Maybe what I do is I I do every single one of these is a hyperlink, right? And so if I have to do something that hasn't been described yet I give it the hyperlink that way you can just click and it goes to that, right? But yeah, like you said, I it's weird and so I put control planes up here But like I said and like that exact definite, you know example you gave Yep, no worries All right, everyone I will Catch you guys all later. Thanks for your help this please go in and make changes to this document Unilaterally, and then we can just discuss them or do it through comments if you're scared to break things, but um You know We'd like to get to where we're doing like review As much as possible on Tuesdays or Wednesdays as opposed to always, you know, just putting all of our focus into one document Yeah, thanks. Thanks guys Thank you Bye everyone. Stay. Bye See you