 Okay, so let's go and get started. So welcome to the next Network Service Mesh meeting If you have not done so please add yourself to the participants list so Before we get started. Do you does anyone have any agenda items? It would like added to the agenda Guess we are oh, I mean At least I am adding something in the end I saw something here. I don't know Rampke if this was you which says distributed class use case and the same workflow deep dive Is this a leftover from the previous times or is it something new we wanted to discuss? Rampke Premier so I think I believe what Rampke wanted to give us basically there was a Document that was created with all cleanup done on the use case So that's where I think he wanted to have a quick review on some of the use cases and Overview put the document So let's let's make sure it's added to the to the agenda as well. It's waiting for my My Google Docs actually start working. It's Having a little trouble. Is anyone able to share the agenda as well? This is Taylor. I can share it Great. Thanks. I'm doing it now. Yeah Rampke shared cool. Oh, thanks. Okay, so So we have Some events coming up. So first we have some recurring meetings So besides this particular group, we have the NSM documentation, which is Every Wednesday at 8 a.m. Pacific time and on Friday. We also have the use case Call front out on also at 8 a.m We also encourage people to go to the CNC of test bed Which is every first and third Monday if you're able to make it so NSM And NSM definitely has a good role to to play there So events coming up. We have service mesh day That That is coming up in March 28th through 29th. So I have a talk that was accepted So I need to finish up the last couple things to fully accept the talk We have on April 2nd We also have another talk coming up, which is the Intel out of the box In Santa Clara. So this is at had Intel's site And so I'll be talking about what network service mesh is and and what's and also I I'm organizing to see if I can get them to give me what's called. I basically a workshop So I'm Prem will be very familiar with us The idea basically is that people would get some hands-on experience with network service mesh Over a period of I think two to three hours We have on us coming up on April 3rd or 5th, and we have a few talks that We encourage you to intend to to attend and and to help get the word out We have MPLS SDN NFV Which I don't think we have any talks to but it's worth going just to hearing what people have to say if you're if you happen to be in Paris Container world in April 17th through 19th with a talk accepted by Prem. I Cube con EU so Nicola I mentioned a couple of the talks were rejected. I'm still waiting to hear from some of the others So we'll we'll know for sure what's going on without soon We have we do have a co-located event at cube con EU So the co-located event we we can definitely get some network service much talks there since we're using vital in an interesting way We also have cube con in China and Shanghai for I Don't believe anyone submitted any talks there And we have we finally have on s in Europe in which is gonna be Antwerp Hey, the call for paper is currently open and closes in June 16th. So If you would like to give a talk at on s Europe Definitely let us know and we can we can help Oregon we can help craft a craft a compelling talk Finally, we have Semi F 2019 in November 18th and We have cube con North America in San Diego both of those are the same time So we'll have to we'll have to work that out Finally We have the CNCF talk application. So if you haven't reviewed the talk application We are going to eventually submit The link is in the the link is in the chat We so With that let's go and get into some of the into the main items So we have a kind cluster provided provided demo by by Nikolai So Nikolai you have the floor Yeah, okay, so Can I can I take over just to share my screen and to show some things? Okay Okay, apparently my zoom crushed. Let's see if I share like this. Do you see my screen? It's just starting. Yeah, I'm able to see yeah. Yeah Okay, so we have over the last couple of days We have integrated a Thing called kind So it's essentially a Kubernetes Quick Deployment tool which uses docker images This is the homepage of the project and It essentially is a faster way so this is Essentially not for production. This is just for you know development purposes So currently our main way to deploy and to the develop Is to use a vagrant virtual machines We are able to bring I mean depending on your hardware specs of the of your computer. You are able to To spawn two virtual machines, I mean, this is what we have as a default And then one is the master the other is a worker and then you deploy loads across them with the current Deployment that we have with kind We are getting Let's just do time here. We are getting three Notes to like a master and to two worker nodes And what I want to show you is how quickly so of course the very first time that you have to deploy Because it's based on docker. It essentially downloads and prepares an image And once this image is prepared. So there's essentially this kind of nodes V. Of course This is the version of the Kubernetes that it Yes That it deploys so after that it's just as quickly as what you're seeing now This is a Kind of fast way to To do your development, of course, we already found some limitations like mounting host volumes We know that there might be some instabilities Fortunately turns out we have we Kind of know some some people that are related to the development of kinds or I guess that that it will be a good So, okay, as you see it's just like a minute and something Then essentially you have to do this we have a No, this is the class You can get notes and see and see that you have The three notes that still not ready But Essentially the idea is that that this Makes it more Accessible for people to develop to try it without, you know, all the complex setup that we have up till now You have to download the virtual box. If you are on Linux, you have to use KVM If you want to so all the different things that we have in our quick start guides I think that that it's much much easier to do it this way just depending on Docker and then relying on kind to do What is there? It's true that kind is still kind of alpha version but yeah The other thing that that actually means it's still not You can do infrared deploy deploy all the images but the other thing that We were trying And trying to evaluate is if we if we we we can use this as a part of as a part of our Continuous integration So today our as we use circle CI as a way to build images and then all these images are pushed to docker hub And then from docker hub. They are Downloaded in packet where we spawn physical machines and then we have two nodes Kind of creating a similar situation as what we have with vagrant but We are trying to evaluate how how this project can help us in speeding up our CI So today we have like I think a little bit less than 20 minutes maybe 15 16, I don't know But we want to improve our testing like out more test scenarios and if we find a faster way to spin up the cluster Quickly run tests and then spin down then Then this could help over on the project So that's it. I don't know. I don't know if anyone has any questions or want to see something else So I'd like to point out that Nikolai is using OS X and so this works in a yes Environment and it should work in a Linux environment without any issues Yeah, maybe it's slightly better there because you don't have an additional virtual machine to run the docker Yeah, I find the I find the the power usage of running another VM slightly annoying but acceptable but Yeah, I find In that scenario This this is compatible with OS X and we do have people who are well at the start We have Nikolai and myself who will be using in the OS X environment. So if you're It would be interesting to see how this works in in Windows as well. Like there are some problems There are some problems with make files and so on within within Windows and how and how How it all works together, but It is but it's I think it'd be a good place to start if someone if someone is Really wanting to get windows environment up. This would be a really good place to to initiate that I'm just I'm just suggesting that if they want to get windows that they they it's running They can they can also start with using kind there as well because they can install docker without any issues and So that'd be a good a good starting place Great, is there any questions about this particular environment Nikolai could you please? Tug in the the link to that the kind cluster So that's what I was showing so in in in our master branch. You can find a guide Where actually it explains all these arguments what you have to do and of course we are on I'll see If you have questions you can file issues also on github Okay, okay We also have Romkin Prem who are going to talk about a distributed cloud use case or For enterprise and telco with a NSM workflow deep dive so I'll let you both decide who's gonna talk Yep, I can I will share my screen are you able to see my screen Yes So one of the things Prem and I did as part of this exercise was sort of Not just come up with these use cases, but also sort of look at the Other use cases which have been put together the world use case document and then almost There is a cleanup version. So for example We are seeing one more use case coming together From John if there is potential interest to carry that forward that's from Paul or two So and also essentially clarifying the fact that there are Several protocols into consideration, but it's not a use case for example segment routing. It's kind of a protocol to You know to realize these use cases right some of those clarifications also we added So with that said essentially We have spent some time on the use cases themselves last couple of calls It's quickly like to get the next level of detail. The only change from last time was When we discussed with additionally, there is an internet breakout as you can see so basically we talked about enterprise corporate corporate access last time right traffic coming hitting the P and then going to You will be gateway or escape it in 4g terms for, you know, mobile processing session processing and then heading to Enterprise so the other path is like essentially you directly bake out the internet right from the after you You know Go through your mobile session processing. You don't hit to the enterprise But you go to the internet but at that point you hit a DPA engine the DPA is primarily for reverse traffic But you know to keep it symmetric you pass both directions of the traffic So basically you'll have a fork right at the You know after you do the P gateway escape it gets gateway processing whether you choose to go to internet or choose to go to directly to the enterprise private cloud So Essentially to summarize what would happen is We'll talk about some of the details but from an SM connectivity role When there is in short summary when there is no SRAOV or smart think or any sort of hardware acceleration. There is an additional in additional tunneling needed But if they're using hardware acceleration notably SRAOV is smart like essentially You can just leverage the existing tunneling mechanism because for example gtpu is a UDP tunnel on top of customer packets Same goes with IPsec or L2TP So Then on the SDVAN use case supreme do you want to talk a little more on little on this? Yeah, sure So this is Becoming more common the SDVAN use case particularly with edge picking up Varan the main scenario here is You have core cloud which is which can be an enterprise case which can be a Main data center and then you have edge cloud which are closer to that of the customer premises Where you are providing services There are a bunch of use cases where and it becomes very important So in that case the scenario what we are talking about here is what what would How would NSM play a role in building the infrastructure as well as helping out The apps to seamlessly access the resources both in each cloud as well as on the IT cloud so that's about the SDVAN scenario and also I have just Put the link Varan. There is also in the One that is specific article about how Kubernetes and SDVAN plays a role for example you have scenarios Varan Within a metropolitan Area network a man network you would essentially have the Kubernetes master Sitting on the IT cloud and you would have the cluster formed across this edge cloud and Another important thing is the edge cloud has to be really efficient in terms of its footprint beat hardware or software and also in certain scenarios this edge cloud would essentially be Instantiated And then it can it instantiated based on the requirement and also brought down once the requirement is met So so this is primarily Varan. How do you play out edge cloud using Kubernetes NSM? Yeah So before jumping into the connectivity you walk through So it's a you know, how NSM plays a role I do want to point out I just sent an email from right from the Kubernetes scaling group So essentially a distributed and as cloud scenario, how will Kubernetes work? So essentially a potential Potential deployment model could be going beyond Actual physical data center where basically latency is the order of microseconds to you can take it to milliseconds basically Decase there is you know, like an enterprise as devan or the telco distributed cloud where a hub site Which could cover several small? Ed sites like as an example an enterprise example is the branch office right probably just have one server there It's in cover. You don't need to install a Kubernetes master there But as long as the hub site is within a few millisecond away latency away record and officially confirmed by the Kubernetes six scale group with that Or essentially the millisecond you can call it metro distance right within a metro it should be fine But definitely not overvan, right? But also the key point is you don't need to have a Kubernetes cluster in each and every location Like if you just have a single server, it's not necessary to just dump a Kubernetes cluster there With that so going to the connectivity walk through so essentially there are three layers, right? So coming from inside out, right? So the first is of course the tenant or the customer payload, right? So basically There you have the tenant customer overlay or the IP header overlay L3 or the IP header or overlay L2 or the max header, right? So this is tenant or customer information. This is true for all cases are again the next level of tunneling for all cases So for example, we saw You know IP sec being used with both in the distributed telco cloud use case or in the SD van use case and segment routing of course the tunneling mechanism of which is popular more in the telco world but it's very much possible in the enterprises V1 because it's typically multipaths you have the Packets of the internet using IP sec But then some critical traffic would go with MPLS network at that point you'd be using segment routing and At that point the tunneling could use other MPLS IP tunneling mechanisms, but the key to note here is this is essentially a talking underlay here and in this case all these packets are all routed, right? I mean So basically the fundamental mechanism. It's all routing at this underlay level Right and L2 header is basically providing the max header, but the packet is still routed you at each Routing hop you look up the mac address and you take action on it So now as you peel down the layers In if there is sri over your smart Nick so essentially what happens is at that point you can you have the mac address to Process either it could be if the global mac address it could be processing directly or if you want to deal with private Mac addresses then the you need to bring in the outer Wheel underlay or outer wheel and tag also into the equation right to model But what gets interesting is if in the absence of SRIO in smart Nick. So what happens is? From a host perspective you have only one mac address exposed right typically one or a few right? So then that's when you go with a tunneling example. This is the x-lan, right? The typical one I mean it could be the x-lan etc as a right come could be Jenna or something else or so the rational for here essentially what you're doing is You're still routing with respect to you You know the underlay, but you're able to come convey the entire L2 payload I mean this whole payload everything, you know Including the GRE or IP sec tunnel is a payload for it, right? is you're able to convey to your part of interest or Kubernetes managing VM VM of interest and This is kind of nicely depicted in this workflow here, right? How this is flowing through From NFC one to NFC two where essentially we are depicting to Essentially there are two interfaces and this example is also catering at the multi tenancy There's a single tenant then you would just need one additional interface I wouldn't like to besides Kubernetes interface, but in the case of multi tenancy and if you want superior isolation, this is a typical deployment model and with that background so essentially what we said was Let's go into now what the current NSM scope looks like and what we need to do and Thanks, Frederick for the great discussion. I think we did Talk about a lock of a lot of this last Friday, but we will double click more on this Before we go on is is it possible to share the the Document or that I miss it so that other people in their own time can can also review. Oh Yeah, this one is also thanks to Nicolay is also published actually this document Yeah, yeah, yeah, I'm gonna put this So I think if you click into The use case calendar, it will have the meeting notes on this document Okay, right So the current NSM scope supports I mean again to be very specific one endpoint for anything the network's at least description, right? What if I'm a description perspective? But then and of course it supports software and hardware actually to see an eye from interconnection. It's like very flexible Working with the device plug-ins and then automate the end-to-end Or non-creator spot endpoints also like the ENSF, right? So so now if you the enhanced NSM scope you're looking at a sort of a We definitely need from a multi-tenancy use case perspective support multiple endpoints for NSE the network service description so the the in In basically if you go externally we call it nsd network service descriptor so basically from that perspective, right? For multi-tenancy. We definitely need to support multiple endpoints If you go to long I mean from a long term This is actually really looking at implementing a full-blown HPA policy and there are different types of policies But the thought processes for a simple I mean first step This is actually could be one of the HPA policies where Typically, there's a fault in it in the path scenario There is a fault in an endpoint that typically it's an indicator of the good problem because you will be hitting Essentially the you know both the endpoints no matter what even if they're going to different network functions We'll be hitting the same hose perhaps the same. I mean the nick are the Or the socks which we switch right so basically one HPA policy could be simple in this case We just killed the entire network function and recreate the part, right? I thought this is a good first step, but essentially this is coming to implementing full-blown HPA policies and Daniel others were experts in segment routing know this more than me So basically it's pretty elaborate. How you want to fail over and take a different path, right? You know routing paths, right? So the next one is essentially again the use cases multi-tenancy, but this is getting into another detail All right, so basically We talked a little bit about you know Say the case where how you manage the two cases, right? So one is the SRIO we are smart nick is there. How do you manage the MAC address site? so basically It could be a global MAC address or outer MAC address and you know, which could be private and then a VLAN But also the more important one is Essentially, I think you have to capture the detail here. So the Support endpoints par grouping for interconnect policy. Let me explain a little more so let's say we went to the domain where Essentially, there is no SRIO smart nick, which is a very popular case. For example, using VBP or OBS or you know Dmware v-switch, which I think there's so many v-switches, right? So basically what happens at that point? You have to critically look at how you manage the ID space One simple way is say, I mean if you're looking at VXLan one simple way would be go back and say, hey All these interconnects. I mean, you basically have a network service description Which which has several network functions and you can say hey all of them belong to the same BNI All right, basically there are point-to-point connections But you make that simplifying assumption same BNI and then differentiate based on just the method, right? So this is a scalable approach Versus you say hey, well, I'm gonna I need fine-grained isolation like each of the Interconnect password need to be completely isolated and then start using BNI then So basically you could say scalability issues in your deployment So some things to that is an important thing to keep in mind So that's sort of the notion of the end-point that grouping for interconnect policy, right? So So basically we need to have this policies, but we can start small saying, you know One simple policy could be hey It's just either I mean two or two policies one is full isolation or no isolation keep it simple But then we can start going into more fine-grained policies as we make progress And also do want to stress the point all these standard tunneling points Mechanisms which are using or the more popular ones are always routed from an underlay perspective, right? Basically each hop is a router. That's how these I mean the popular tunneling protocols are and Essentially the next one is around traffic management. So basically Based on the interconnect policies and also the multi-tenancy you you basically support Interconnect usage monitoring it could be construed independent of the previous one also no matter multi-tenancy or not We need to look at interconnected usage monitoring, right and figure out what is going on from an interconnect perspective, you know packets in now and then you can take it to and This could be for example useful for figuring out if there is some sort of DDoS attack happening, right? and then take further action and This is to second the next one is more of a repeat saying this should be done for both software and hardware activity C&I not for one or the other right the same interconnect usage monitoring and The last one is essentially support bandwidth management, right? This is the again a very interesting and critical one So the use case is QoS. So if you look at the You know the compute side K8S supports elaborate policy for example, you know for their service there are three levels from a compute perspective that a CPU and memory you call it best effort Or guaranteed or a min guarantee model, right? Or best effort min guarantee or absolute guarantee Right and in our case This would also entail K8S scheduler changes if you want to go that route but we could come come through that a long-term activity, but as a first step at least You know building the enforcement which can happen right at our layer itself to the C&I and for certain either you're using the Software software path or the hardware activated C&I This is sort of I went through a little fast and now completely open to questions and deeper dive So I had one you sort of wave past Segment routing and VX LANA kinds of overlay. That's fine. It's all good, but there's a problem there. I think of Who's authorized to use which kind of overlay if you were doing the enterprise use case that you suggested and used SR then that simply wouldn't fly because There's somebody in the middle between who's got to agree that SR is actually permissible and workable so I Think if you I mean, I'm guessing that one of your next steps here is to break this down to some sort of call sequence I think when you do that, then you've got a cross administrative domain issue that will show up So you're talking about the segment routing use case Well, I'm talking about using segment routing segment routines at all It's not a use case and to be fair your point about quality of service is the same. I would argue. It's a tool not a use case Oh, sorry. Sorry. Yeah, sorry. It's like so segment routing Yeah segment routing tunneling mechanism. So I didn't fully I mean, it's it's still even if you're doing segment routing as a tunneling mechanism. It will still be The packets to be routed, right? So what within the tunnel the packets will appear to be rooted. Yes, I'm not debating that I'm more trying to work out how Your I mean we're NSM here. So the question is how you set up the mesh and so The question I'm asking myself is how I would set that measure with a sequence of calls to NSM managers and That's where this sort of loses its track Yeah, I to add on to what to what Ian is saying and correct me if I'm wrong So like people it's it's not that someone wants segment segment routing is that they want some They want some feature functionality that could render into They could render into segment routing and so So part of so part of what would be useful, I think would be to try to work out What is what is that high-level use case that? That we can drive towards to say then segment routing can can help with this scenario And make sure that that that use case works as opposed to just saying we do we do segment routing Yeah, I could do ready the thing is that overlay. It's not clearly a network service endpoint but nevertheless that overlay is an important a significant part of the The the mesh that you're setting up. So you're asking for something specifically by property and I'm not quite sure how that request would happen and again particularly because this crosses an administrative boundary between an enterprise and a service provider that's quite an important question because the The call might result in asking the service provider for something rather than asking segment reaching by name Yeah, it's the same advice that that I gave to the network service funding group on their inaugural meeting when they were talking about multiple interfaces and it's like Okay, it's not the thing those people want is not the multiple interface It's actually you have to look at why why are they asking for that feature? It might be for a faster data plane or it might be for something that they can get more more predictable performance or quality of service on In in in order to solve a very specific use case and the actual quality of service mechanism or The fact that it rendered into another interface is is not actually what what the user was was looking for It was just a means to an end so So we should we should try to work out what some of the more popular things are like why why do people bring in a service? SRV or SRV six is an example and then ask question like, you know, why, you know What what use case do we drive from from that? So like basically like step up one level higher So, um, so that's at least the thought process and I mean basically this is So there are two aspects to it, right? Of course if Protocol like SRV six bring some additional value more I would say with respect to The end-to-end service itself sort of maybe you can argue QoS, correct But we also have to look at Look at what does it exactly mean from an NSM perspective? At least if you go back to These Architectural impact, right? So basically the use cases it would sort of then fall into the QoS aspect perhaps, right? Or the traffic management more towards that. So basically segment routing If you're using segment routing, you can do some fine-grained two ways between these two end points and then the way That will actually percolate to NSM is more of the QoS, right? Okay, or even classic MPLS you can do bandwidth management, but it's sort of more of the implication rather than Anything else is the thought process, right? Yeah, but again the problem at the moment is is you've got Use cases described quite well and implementations You know components that you can use to implement those use cases and NSM is the glue between the two And I'm just not seeing the link here. So the the really it comes down to Effectively use cases tools and how NSM would assemble those tools to make the use case work And I think that's what this document's a little bit scattershot in that regard at the moment It mixes together and it's not clear separation between them So Yeah, yeah, and so the the bad aspect essentially we are I think probably Are you looking at sort of so now once you have clarity and we have Some idea of what you're going to do I mean we want to double click into sort of a workflow to make that bring that clarity saying hey This is how it will look like or Anything else because I think many of this is it's probably Clear and people who are extremely similar with this in their mind, but sort sort of it still not Reflecting the workflow right? I mean I think I mean to be fair I'm pretty damn familiar with service provider networking and the use cases that you're explaining and Yes, absolutely. I think that's exactly what you should do. You need to double click into What the calls would be to NSM to set this up and would be on failure as well because you sort of hand-wave that one off slightly Because that is precisely the detail we need to actually work out whether the current Description of NSM actually applies to this use case or whether we're missing something and that's what we need to understand If we're missing if what we're doing isn't quite going to work then then you know examining a use case is precisely how we fix it Yeah, I agree Yes, so I think a good way to start as well as if you if you scroll up to the image that you provided So So if we look at like this particular Scenario where we were actually ignore the fact that's NSE or OBS or physical Nick and just imagine like the standard You know, you have the some some client connecting to some set of services And you could build the chain out longer if you like and the fact that there's two connections here What you're trying to express is that is that multi-tenancy? So we start with that basic premise and then we start asking the question like how do we ensure? Isolation between between the two customers How do we how do we how do we ensure the user gets the throughput that they're looking for? How do we ensure the user gets the security they're looking for with with NSM? How do we ensure when a failure occurs with a link or one of the services that they get rerouted? And so I think if we look at it each one piecemeal in that scenario To start off with and that that would probably be a good way to start And then what we can do is starts to compose them saying how do we get auto healing plus security plus Plus whatever and start to drive to a to a full end to end Use case so I think that you're starting off really well like you're asking the right side of questions the the feedback I think is that Is to focus primarily at the top level use case like what is it that we want? You know if we had 30 seconds to to tell an executive Who is going to make a decision on this what we provide them? You know we saying things like oh we provide quality of service and we provide you know Those things are important, but we have to be able to drive a Effective narrative that helps lead people to see how this solves it at a holistic view Yeah, I would argue in fact the NSM is job isn't to provide quality of service It's to provide The ability to connect services together that give you things like quality of service as well. So exactly just And that's what I'm trying to understand from your document. You've reeled off a list of And again part the problem with the document is it's a mix of two things together One is high-level use cases which should have under them You know enabling features that will make them better and one perhaps is low-level features that you might use to enable those use cases But the more important question, which is completely unanswered as yet, which is totally understandable is how NSM Enables you to use the features you're talking about to deliver the use cases that you're interested in and that's what you've skipped over in There it's just you've mixed the two up and then the missing component just isn't obviously missing I think Yeah, I think Yeah, those are the fair points. I agree with you and so what we have done is essentially We took a more of a top-down approach where and first define the use cases Then get into the details of what would be the requirement from a NSM perspective and I agree as a next step What we can do is we can identify the components and then more like a call flow or a sequence diagram between them Which essentially enumerates the details on how things would Would essentially look in both the use cases. Yeah, so Pull pull your implementation bits out from from the use case For the time being and stick it in a separate section So it's clear that this is the use case you have and these the building blocks you've used to solve it And then you know the answer the demonstration is how you glue the two things together Yeah, I think it's a very very fair point and I'll definitely we will probably definitely look into it and Just to other aspect was like precisely this in a sense you wanted to get some early feedback the agile and Yes, this particular step what you felt was you probably need the experts such as Fred and Nicolay, right? I mean, so who know the code inside out, right? That matter so basically they are the people who have been looking at the workflows and you want to make sure first of the have at least them You know basically direction. We are sitting here with the distributed cloud and as it looks like I think there is good interest and also basically alignment and This is more of saying first setting that stage for that That's what we are thinking in mind rather than if you do everything and we find that oh my god These use cases themselves are busted. Then it's a bigger problem. You're facing, right? Yeah, that's precisely it I'm trying to make sure and it's not about the fact that they know the code. It's about they fact They know what they're trying to do But yes, the point about your use cases it evaluates whether their current thinking is the right one or whether we need to change Direction slightly. That's exactly what you're trying to do. Yeah, just to Just to be clear. I think this is a fantastic start like literally we've had what one or one or two meetings at the most two meetings and when we're already up to to having this information Discussed and in a in a scenario that is that is digestible. So so so I do want to make clear like you're off to a really great start so we So, yeah, we just we want to make sure that it's that this thing is heading towards a towards a direction to To make it very very clear as to not only what is it what use case? We're trying to solve but also make it very clear like this is the part that make network service mesh provides And then this is the part that you have to plug in, you know Things like firewalls and so on like we're not going to provide a firewall for you but you can bring in your your favorite firewall Provided you can you can plug in or create your own endpoint for it. So So in that scenario like I think I think this is a fantastic a fantastic start. So I'll definitely make sure my time is available to help to to help you Work out Not only high-level stuff, but also details as well Thank you for it will continue for the call flows because yeah, we need basically you have a thorough understanding of what is there and you know, how things are lining up. Yeah So Yeah, I think even before we get into the call flow right what I was thinking is at least zoom into further details on How would it? How would a typical deployment look like right and then what we can do is we can bring in call flow So that's what I was thinking probably one level of further Getting into the details on for example Beat an edge clone or beat in the scenario. What would be the components? What would a service be and what will happen when a service gets deep but things like that? Yeah, yeah, certainly, I mean and in fact that's that we could even Whiteboard it out. Yeah, possible rather than I think I mean basically and then the agile and a little bit faster like whiteboard and then of course Capture all those pictures and then quickly progress the call flow step because that's when we bring to this audience then Be clear on who's doing what right? Absolutely. Yeah. Okay So before we finish up, do we have any last? questions in this particular topic also We are probably calling out for more people who can get in because definitely this is this team has a lot of experience and Probably whoever is interested can probably join and help us in defining the details Because once the rubber hits the road then you definitely have a lot of unknown or a lot of questions and more the Team size better it is as well. I have a standing conflict with the Friday call, but I'm hoping to eventually reschedule that Because I have a lot of questions on this Especially since it tries to like span both the service provider network and the enterprise network and the considerations for like What it actually means when an enterprise peers with a service provider directly like wants to become a BGP peer this and that like I think a lot of this stuff looks good on paper And I think that the technology is there to support it But that doesn't necessarily mean that the business processes or the way that service providers on board customers necessarily is there to support it unless you're Surely just going to ask for you know a BGP peer and then do tons of tunneling over everything or you know I saw SD WAN was in there But like I said, that's even that still You could have an SM make all these calls to the SD WAN But if it only controls the overlay then nothing actually happens on your underlay And so you say increase this to 500 megs and you still only have 100 meg line I mean, there's lots and lots of considerations if you want to start playing in the service provider space that I think There's just weird caveats that don't apply in the enterprise space that will have to account for Another way of looking at it is you're almost trying to change the world by giving service providers API And that actually might be the right answer for what it's worth, but Well, that's what meth is doing, right? So I mean like you said well And that's what we've been working on like when I've been like working on like the meth standards for API's and stuff is like If it like Romkey, I recommend you Google after this I'm just looking to the interlude API and the Sonata API and stuff and at least, you know Charter and a few others we've been looking into the meth space on doing exactly what Ian just described where we present an API and If resources available, you could potentially make requests for changes to the underlay. This is still in its earlier ly infancy But um, it's something that at least in the Ethernet space like standards and you know Day models and whatnot are starting to like See their infancy. I mean I worry that like anything in the service provider space There'll be 15 different standards and then nobody will use them, but these are considerations And like NSM at that point and this is where Mine and Ed's definitions of data plane get a little wonky because in this case that interlude API for service You know modification to the underlay would essentially be your data plane as far as NSM's concern And you would make a request to the service provider to not only you know Get that overlay change what you would do to the SD-WAN platform But then also make a request for the underlay change so that you know the MPLS configurations Underpinning everything actually bump your circuit capacity up Yeah, I think Ed's view on it is sort of like a certain phrase about turtles all the way down applies You know, it's data planes all the way down Right The model we're going with that's fine But in this case like I said, I mean the service provider itself is the data plane, right? I mean you could make that argument because it's what's passed in your packets for you in your frame So I get it. It's just it's a nebulous way for me to look at it as a service provider engineer But then at that point, yeah, like in a sim would only be calling interlude Sonata versus, you know, you're not going to go into provision some service providers interface, right? Like on a switch somewhere like in a hub or underneath a cell tower like zero chance that that ever happens So if this API thing comes to fruition and methods successful Then that might be how a use case like this fully materializes from end to end Yeah, I think we can't absolve ourselves of this by saying it's all the data planes problem Because in many regards the data plane here is just another kind of service again, particularly when it's it's cross one and it's got specific behavior So, you know, we have to deal with the consequence of having Services that people bring along that implement, you know, end-to-end connectivity Yeah, I And the question is going to be what what are you doing? What things do we want to lift from the from the data plane into into NSM? So we can so we can do the right kind of negotiation between disparate things so That's that's going to be a very interesting question and may actually be different between certain Between certain types of data planes So so we definitely have a lot of things to look at in that space, but with that we're we're actually out of out of time So yeah, I'm good point and also good point and met for Jeffrey So similarly, probably we should also be looking at if there is anything to leverage from Etsy, right? I mean they have I'm not saying they run a fantastic job on the network service descriptor But that could also be leverageable. I mean as public as we walk through all this and So one request to the team. So if you think do you think that this Friday is a little I mean basically Not the most convenient time the Friday morning. I mean, I can't make it, but I don't I'm one person the collectives More important. So I'll see if I can move some stuff around but Fridays are at the moment a hard no for me Yeah, my my recommendation is if we're worried about people not being able to show up would be to run doodle poles and see if Like Friday versus Thursday Works but I Know that Ed has has a conflict on Fridays So I'll definitely I can definitely show up to them, but yeah You're right. I mean you ran the doodle pole between Friday and Monday and so We and we do want to keep the meetings to before 9 a.m. Pacific, right? respecting I Anyways, let's let's talk about this at a at a later time because we're we're starting to go Yeah, I will then Thanks, Fred. So we'll we'll probably it'll be great if we can meet up and then make some offline progress especially in the workflows Sure, I'm happy to I'm happy to do that as well as long as we share back and discuss in the community Okay with with that is there's If there's no other urgent News then thank you everyone for for your time and we will see you all next week at the same time. Thank you