 Great, thanks for having me here. My name is Tim Hsu. I'm a network sales engineer slash project manager for Dorado software. So a lot like Beyond Edge and a couple of the other partners here today. We have a set of software around management and everything else. I'm going to hit a little bit on it at the end of the slide at the end of my slides just so you kind of know what we do. But my main purpose is actually to go through with you guys and talk about the customer experiences that I've had and and the customers that I've interacted with, how they're using Sonic today in real enterprise environments, not necessarily kind of in the Microsoft, you know, initial use case scenario of a cloud and in the traditional sense, at least from that. So that's my plan. Take you guys through here. Got a couple of slides to just the first one, kind of just key up kind of what the enterprise typical customer expectations are for you guys and then talk about how that expectation and that environment and all that flows into the data center and telco customer examples that I have. And then last, I'm going to end on the edge in in campus style use cases, which as Beyond Edge was just saying, is definitely a very big game changer for Sonic, I think. But I definitely see that feature gap closing very quickly. And then last, I'll talk a little bit about our solution to it and have some Q&A. So these enterprise customers or telco, large telco customers that I've been interacting with have a lot of these kind of built in legacy kind of mentality. So you have a lot of these kind of ideas where they think they're buying monolithic tools or buying a set of things that they expect to just work, right? They expect these components of what makes up their data center or their environments that are, you know, spread across multiple data centers in many cases, the tooling and then the applications that they're buying or the operating systems that they're running in the case of like VMware, they want high integration and things like that, right? So these are kind of the expectation world that these customers are coming from when they start to look at trying to use Sonic. So the data center and telco customers, this is the easy kind of use case for Sonic today. I think this one really is pretty well met. We can meet pretty much all these needs with customers. The industry has definitely gone to the EVPN, VX line overlay, underlay technology, the layer three stuff is all, you know, tried and true, everybody kind of knows it. So I feel like this is the easy spot for going into Sonic and these enterprises. Most of the time with these customers, the conversations that we have are around, you know, they want a protocol that maybe is vendor specific or they want a specific thing to integrate with something else because that's what they're used to. And a lot of times this conversation turns into what is it that you need from the network? Like what is the problem you're solving by protocol XYZ, right? So a lot of those conversations really change the operational mindset of these customers. It makes them start to think about solving the problem and less about the protocols and the technologies and the RFP checkpoints for lack of a better term if you've been doing this for a little while. That really does force a bit of a game changer. And for me, this is what I think makes Sonic a lot of fun for these customers. I can go into these customers and say, you know, you don't have to worry about the protocol, but what problem are you solving with your customers. And a lot of this turns into that automation and tooling that we talk about we've talked about even in the first slide today, it really becomes very interesting of how you can use a tool like Sonic, how easily you can take a container, add a container, change something. You go to put it on the edge, you can you can slim down some of the containers that maybe you don't need that sort of stuff, right? So it definitely becomes very interesting here. I've seen quite a few of these go to deployment. These are the easiest ones. Like I said, scale is almost never a problem. All of these are smaller than where Sonic came from, right? A lot of these are data centers of, you know, a few hundred racks at most, right? Any questions on this kind of customer? You guys feel like this is an enterprise customer. What am I missing? Nobody got any thoughts? It's the easy one, right? We do a lot of this integration, by the way, with more than one software vendor. So a lot of times we're putting Sonic in here as the spine and something else as the leaf. That was the first way I did a lot of Sonic stuff. And we'll also be doing where like you was talking about maybe a customer wants to do a migration and some sort of like brownfield flashed greenfield environment. They might prove this out in greenfield, do a whole pot of Sonic, and then they'll look at this old environment and he's not in his head, you get this too. You want to do this old environment and they want to replace something with, hey, we're now into Sonic, can we replace this? So this becomes a lot of fun. You can get these customers to make these changes. They will do it. This is very doable. So the next one, and what I think is the most interesting one lately is moving Sonic onto these edge use cases. These are the customers. These are the environments for the customers that a lot of times if they're a retail customer, which I've dealt with a couple of these, or a customer that looks like retail, they have a lot of remote locations. This is where Sonic is an interesting mix because it came from a layer three world. It came from that sort of stuff. The platforms and expectations that customers had in the past around this, around what a layer two campus should look like, whether it's a traditional campus, even in some cases, I've dealt with universities and schools trying to do this. Their expectations of how it should interact, what protocols it needs, does it do NAC, does it do these sort of things? These are things that we do need to invest in and get the rest of the way there. Some of this is working today, depending upon the particular distribution or vendor platforms that we're on. But like you were saying, we see a lot of need for Sonic is CPU hungry. It's very resource intensive from an operating system and network operating system platform. The good part is it empowers the customers to see the value in what they're getting out of that. The bad part, of course, is that means that that same switch they used to buy for a smaller amount of money now might cost a little bit more. It's investment in hardware versus other things. So you're trading that off. But here, the other thing that I find very interesting is customers are coming up with very innovative ways, at least with me, to use the overlay and the underlay idea. They're building non-traditional spine and leaves. So they'll be going from what would be in the campus called a core network, which you could read as a spine. And then they will build an IDF or an MDF, and then from there they might attach another whole set of leaf switches. These customers, the big thing for me has always been abandoning stacking. And that's where the automation and tooling come in for us. So if you can prove to the customer that stacking doesn't solve a problem anymore because I can automate you around that problem, that's a huge thing. Not in your head. You've seen it. Yep. Exactly. So this is where I think a bit of a change in the hardware platform is going to come. And I think you're not in your head the same. You think the same thing. I think we're going to end up with some sort of intermediate device that would be a potentially more powerful leaf slash extension spine, something like that. So whatever that's going to be where you're building, I wouldn't call it a three tier, but a multi-tier. When you move to a, certainly like universities, I've had this, where they put in on that edge, they'll put in a larger pair of switches at a break point where they might have another 10 switches below it or something like that. They'll want to use those ports to put end users on, but they'll also want to use those ports to aggregate the switches that connect upstream. They're also building HA within this company. So these customers are doing this today. I mean, I have done deployments with universities. I've done deployments with retailers and with very traditional kind of campus mentality where they have a need to do something. I've done distributed HPCs, which are actually really fun. So those are good examples of this. But this is where I think Sonic is looking at kind of a bit of a break point. I don't know if you're looking at saying, do we need to create another version of it? I think that's probably a bit overkill, but I definitely think potentially looking at how do we make it fit within a tighter CPU boundary or maybe there's some recommendations we can help customers with of, hey, these containers may not be needed or trimmed down something like that. I think that's something we could definitely do some time and effort on. And then the kind of last spectrum, the kind of last spectrum I had here was just to kind of contrast the customers that I interacted with between that build versus buy continuum that I talked about in the kind of the first slide. And this is what I see a big difference between customers. There's a lot of the customers that are kind of on the extreme end of wanting to build it themselves and those customers might be all the way to the end of, hey, I want to go get my own, build my own distribution of Sonic for in-house use and everything else. And then you kind of have the other extreme that just want to buy something off the shelf that just works. And I don't want to worry about what build of Sonic on. I don't want to go look at the list of bugs and make sure I pull in the ones that I want. They don't understand that mentality. So I think there's a huge space for us as partners to fill these voids and to help these customers and kind of help them understand to the point of the guy presenting earlier. I don't think Sonic's all necessarily about saving money. I think this is very much a game changer from the standpoint of a customer owning this and taking responsibility for it. So I like the customers that, and I think most customers like anything, you're to build a spectrum of left to right. Most people land somewhere in the middle. Most of my customers are landing somewhere in the middle. So we need to fill in that that perspective from the middle. I think the two ends have been pretty well captured. Right? So that's kind of the last slide I have on my own product. That's where I think we fit in really well. The automation and tooling product that we have allows the customer to kind of do both sides of that game and complete that full cycle for them. They can be as independent as they want and they can go and use our product like an out of the box kind of vendor agnostic management platform. So make sense? Everybody's been quiet all day. So any questions? Yes. Yes. So you mentioned that you would like to see the trimming of the distribution, right? To fit into smaller CPU or maybe hardware boxes, right? When you talk about this slide. Edge, do you have an idea of what is the hardware size that you need to fit into? Hopefully you're not looking for some super small ones, but just trying to get a sense of where are you targeting for, right? Or what is the distribution? Let's see. If you get down to this size, you get to open up this much market. If you further cut down, you get to that much market. You do have it. I guess, and I'm looking at my peer here slash competitor at times. Yeah. So it ends up being a combination of the chips that you need to support Sonic. So the more cost effective chips, I'll say, aren't always included in the side today. So that's one factor. And then the other factor is the CPU kind of hungry side of it, which is being addressed. It's not as bad, but it still has a little CPU and memory hungry. So I think those, but combination to his point, and they need to switch hardware platforms. I mean, I would say, although I don't sell hardware anymore in heaven for a little while, I would say there needs to be some less expensive hardware in the market. Yeah, it needs to be, I think port density is another equation, but most of my customers today wanting to do this on the edge are okay with 48 port switches or whatever. But if you, if we really wanted to penetrate this market, you're going to have customers that want 24 or less port options. Because this is where, yeah. And, and that's essentially my experience as well. I don't think I don't think you're going to have a lot of customers wanting to do Sonic on really, really low density cheap switches. I don't think you're going to see a lot of customers wanting a 10 or 12 port switch doing Sonic. They just go buy something and plug it into their network. But exactly at that point. Yeah, price is almost the single driving factor at that point. But, and they view those as disposable largely. So, but I do think there's a need here for some lower end. And to his point, I think the chips at family matters too. So today, when you're looking at the chips, you know, supporting the EVPN and all that other stuff, they're usually pretty expensive chips. So even within the market, we have chips, you know, that we can get a little bit cheaper that do support Sonic, but then we lose the EVPN support. And I know about you, but a lot of my customers are like, no, no, we want to use that on the edge. So then it becomes, how do we get that in there for that price point? Yes. That's a good point. Yeah. So the campuses that I did recently were large enough, they weren't using SD WAN. So yeah, but if you're doing an SD WAN to it, then you could do a strictly layer too. Correct. Anybody else? I mean, these things, these things already have pretty underpowered processes in them. I mean, at the end of the day, you know, the incremental cost for, you know, an extra cause, what, 150 bucks? I mean, in the big scheme of things. And so we talk about trying to carve all this stuff down. The amount of engineering costs dissociated with sitting here trying to squeeze this thing into a $600 box far outweighs the cost associated with, you know, spending another 300 bucks a box. I mean, this is, I've been involved in this conversation over and over and over through the years. You should use this particular nick inside your servers because, you know, you'll save, you know, 10% on your processor time. Now, this is not dash. Dash is a whole different thing altogether. It's like, yeah, but if I do that, and now I've got three different types of nicks and five different types of servers and all these different use cases, the amount of incremental engineering costs are going to go to manjulist stuff. It's ridiculous. And this is the same argument. I think that in this, we do ourselves a disservice by putting insufficiently powerful processors in our switches. No, understood. Yeah. And in coming from a past life where I was at a hardware vendor for a while, I can tell you that your argument is not necessarily unfounded. They, you know, they would choose to put, you know, it literally cost them a few hundred dollars difference between the chip that they would put in, and they would choose to put in the smaller chip because they could dictate the OS to fit within that chip. I think moving to Sonic is a bit of a game changer for customers knowing that they actually are going to use more of that CPU. I mean, we were having that conversation on one of the breaks earlier of how do we use the, you know, how do we make use of the CPU? Do we make this service go up? And then what's the, you know, how much before we tip over the CPU, right? I do think there's going to be, and customers want the streaming telemetry and they want this other data off the edge. So those same customers are going to end up, you know, wanting the CPU to be bigger anyway at the end of the day. So to your point, I think maybe it is a bit of a learning curve for our customers to realize that there is something in value to have a little more expensive switch. I just think from my experience, my customers, you know, what they've said to me is the ones that are coming back for these edge use cases are saying they need a little bit more cost effective. Should it be at the cost of the CPU? Maybe not. Maybe we could look at some chips from, you know, some of the, from the, that could be onboarded by Broadcom or some of the other partners in this community that would be more cost effective and still have the features that they need. And to your point, they don't all need VXLAN, right? Yeah. And I go, why is this one the same price as that one? And they're like, what are you talking about, Adam? It's got, this has got 48 ports of this and 57 ports of that and blah, blah, blah. And I said, do you guys know anything about Sirties? Do you know what a Sirties is? And they look at me and they go, I don't know what you're talking about, Adam. I'm like, so, you know, the Sirties is the thing that really matters here, not what the front of the switch actually is. And so this switch ought to be far less money than this one if we were getting the same discount across them. And guess what? We got the same discount across them and the price of that one went down. And so I think when I talk about procurement, I talk about how we manage the supply chain of how we buy things and the understanding level of buying things. But I think we do ourselves a real disservice trying to squeeze into these, into these very small processes. It's always been a continuing problem. You put a life cycle on this thing of five years and you find out two years down the track that the Switch A-stick will still do all the work you needed to do, but you can't run the software anymore. Yeah. And those of you online, he was just saying that we just need more choice in the market, which I do think is where I'm going here to. What's that? It's handy for you at home. It's handy for you at home to do. Yeah. Yeah. Yeah. And I do think there is a sweet spot here where the customers looking to do Sonic on the edge are willing to buy into the idea, like Kei and I were both saying. We don't see them asking us for small density, very, very cheap switches, but they are asking us for something more cost effective than what's in the market today. At the cost of the main CPU, I think that as a community, like I think that's a decision that the technical leaders need to make. I'm not in that position and I'm okay with that decision. I just think we got to figure out how to onboard something. Well, I guess my point is from a Sonic decision makes probably the wrong word, but a Sonic community, I think that was the heart of your question is, how small do you expect the OS to go? And the answer is, I don't know that I have the answer, right? The answer is, I think it comes down to can we onboard? I mean, personally, I would say, can we look at the market, see what's in there? And maybe it isn't the CPU and memory that's the problem. Maybe we just need to onboard some other couple of chips in the PSI. And to your point, I don't know that a smaller CPU and memory is necessarily the right answer. I do get the feedback from customers that a more cost effective box is needed, or is wanted, maybe needed, strong or wanted. So, yeah, thank you guys. It was a good debate. Hopefully it made you all think. But yeah, like he was saying, there's a lot of progress here. My last slide, there was just my little nod to all the Star Wars fans. I really do believe in Sonic. I've seen it make a lot of progress since I first learned about it several years ago. I've been in a couple of different jobs advocating for it now. But yeah, I really do think this is going to be a very popular winner in this open network operating space. So, thanks. Appreciate your time.