 I'm fortunate to have to come on stage after Adam because I think he simplified some of the problems we are here to solve. So we are excited to be members of the Sony community. We joined not long ago. We actually joined the band wagon pretty late because we took the approach of wait and see. There were a lot of initiatives coming and going. So it was a smaller company. You can jump on every bus that passed by. You don't know where it's going to take you. So we didn't want to do that. So we took approach. But then we started seeing the momentum that Sonic is coming in. Grateful for Microsoft, all the work they've been doing. For those who joined the outreach community or the technical steering committee, you see how much work is going into that. So what we are here to talk about, and we have some partners in the community like Dell and a few others that I cannot mention yet, we are here to solve the problem. But we are also here to enable the opportunity. When I pre-came over here earlier today, you saw the growth in the enterprise by 2027. I think with the right tools, that growth will be even faster. More than 60% of the ports that are going into, outside from the manufacturers, everybody, are going to the access that coordinate the gardener. So the edge and the enterprises. So enabling that. Let's see. Is it showing? Oh, yeah, here. I had a different haircut. So what is the challenge? Well, the challenge is not for you guys. The challenge is probably the ones who are listening in. The challenge is for the IT infrastructure, the guys that see the different version coming and coming and going and then getting acquired or whatever. So they don't want this in other noses. Not a lot of people like the previous guys who here before beginning super excited or looking at CLI. Not everybody is saying, oh, I can write that. For them, it's about being almost invisible. They need to provide a service. They want to do it simple, easy, and they don't want to get the call. Because nobody calls you as a system, as a network engineer saying, you did a good job. No. If you get a call, you have a problem. So we want to help everybody be invisible, do their job, and as a network engineer, you know, everything now is driven by networks. So they ask you to do more at the same amount of time. So what our solution is, is a hyper automated intent based networking platform with no need to even interface with the CLI. Now, one thing I want to address before is like people is like, what, you know, everybody's using intent based networking. What do you mean by intent based networking? It's a good question. Because even when you put a network with CLI, obviously add your intent. I mean, nobody does an IT things without intent, right? You have something in your mind, you work it ahead, and then you put it with commands, a lot of CLI. But let me show you a little video of, in my simple mind, what it means intent based networking. And I've been around too. And I love road trips. And the old days, do a road trip across Europe, across the United States, was a lot of preparation work. You know, I spent 10 years in the military. So for me, preparing like the route was a big thing, measuring, knowing exactly where I'm going to be in every given moment, like this, and you do a perfect plan. And then you start, and then you realize, well, storm, it's going to progress less. I have some road closures, road delays, and it's always was a big issue. So my intent was to get from point A to point B with the executed plan. It was never that way. And then came Google Maps. You just tell Google Maps where you want to go. It will optimize the trip when you want, when you start it, and then we'll continue to optimize it through the process. So if there are delays, this will route you. So this is, you know, hyper automation is a key for intent based networking. Otherwise, it's just what you're doing today. So coming back to Sonic, right, amazing tool, amazing NOS with all this, you know, the Docker containers and all this, but somebody has to do a lot of, you know, coding, a lot of commands, a lot of this. Now, for some of you, that will be wonderful. But for a lot of people out there, when I talk to many, many companies, and that's what we want to do, we want to make Sonic accessible. This is scary. You know, you can have Clish, another CLI that makes it Cisco like interface for Sonic, you can do all of that. But, you know, when how many guys here open the hood of your car and look at all the components and know the compression ratio of your pistons and how everybody, everything works, maybe one or two, you just want to drive. And, you know, and that's what this, so we just make it drive. And I like the easy button. But when I listen to all of you guys, I realize it's not easy. It's easier. It's never easy networking, because there's so many moving parts. And, you know, like Hedrog was mentioning there, oh, you know, it should work on this hardware platform. Should is a good word, right? It should. You know, we talked about different this. Oh, everybody, JNS, using, you know, virtualization, all this. It works. JNS3 works. I saw that, you know, but then you realize that when you run it, our actual switches, not so much. So, I would call it definitely easier way, not easy. So, customers, right, you know, they want to create fabrics. Well, you have two types of creating fabrics. First one is Greenfield, right? You start from nothing. You're lucky. You're building a new data center. You do this and you can create it in a simple CSV file, JSON, or with our friends, the Dell Fabric Design Center. So, you can create that tool and then you get an output. In the edge where we beyond edge like to push Sonic more and more. And we have several customers and if you have questions like that, you get the running config from the switches themselves. We call it a brownfield. Why? Because you come in, 60% of the time will be Cisco, maybe even more, and you want to, you don't want to redo the work or everything. You just want to extract the running config from all those switches. And actually, for the first time, tell CIOs what they have in their own network. According to Gartner, 74% of CIOs don't know what they have in their network. I'm sure for some of the CIOs over there, yes, you are part of the 26%. So, our network agent list, you know, Santil mentioned earlier, we also use SSH. The idea is don't touch the hardware. We do that because we are multi-vendor. I cannot install anything on the vendor X and expect the warranty to remain. And it's a constant nightmare, of course, with the hardware changes, et cetera. You just do it with an agent list, work a little bit harder in the before, but then it helps a lot. Install the VMs, two VMs. We can install them in the Edge. We have some customers using them in AWS. They install the VMs, AWS, Azure. That's in the Edge. Data center zone side, basically simple OVAs. And then you import those starting point files, I mentioned, either the Greenfield one or the Brownfield. And you create a digital twin. So, your whole network, out of band, overlay, underlay, everything is installed already. One thing is missing, the actual hardware. Once you plug the hardware, the hardware identifier, whether it's a service tag, serial number, et cetera, will be associated with a configuration. So, in this case, you will see in the demo, three spines, seven leaves, they wait for their respective configuration. Just a simple metaphor, your mobile devices. Your mobile device, you are actually a client of the cloud, respective cloud. I have an iPhone. I'm actually an iCloud customer where I'm caching all certain information on that phone. A lot of my pictures are not even on the phone. They are in the cloud. Similar in this case. Once you plug the hardware, choose EDP, the switches will come only with only DHCP, get the Sonic, and all of this in auto discovery. Questions, how it's done? You'll see a video in a second. Some other key capabilities. I like Apple. I'm sorry. I have friends with Dell. I make a lot of presentations with Dell. I'm a big fan of their stuff, but I like my Apple. Why? Because I have a time machine. I have a problem. I just go back to this time and I have everything. We save running configs at intervals that you decide and restore them, JSON files. If there's a problem, you can always go back to that instance and just wipe everything you have and go back to previous time. We have a customer who had ransomware. He just wiped everything, put the whole new config from a safe point of time he had and helped them quickly bounce back from that portion of their problem. Scheduled and automated firmware management for part of the out of band, upgrading a Sonic version, all of that, automated way you can do logical partition of your network, went to update which version, etc. All detection of hardware, PoE management, also in the same orchestration. You don't have to go anywhere. You can manage PoE 802.1x and LDP on the fabric. So just to kind of a summary of some of the things. It's graphical. I heard here before CLI is great. We are network engineers. Love it. I get it. But for the other 80% of the population, they don't want to see the CLI. They want it to work. You want it graphical. Most of them don't want to learn the Sonic CLI. They just want to see, hey, I have a problem in my BGP, it turned red. I just hover and tell you, what is this red? Because as human beings, we can absorb a huge amount of data in a finite time when it's graphical. It's just our nature. So it's all graphical, zoomable, basically Google Maps of your network. It's not based on database. It's live. The network constantly inquires itself and recalculates itself. So if you take something out of PoE 13 and put it in PoE 42, it will automatically detect. It gives you accurate information of all your inventory of the network and LDP information of what is connected to the network. So if you're in the edge and you have thousands of Mac devices, there's a Mac workbench. You can search that. We can actually show you at LDP of all the devices connected to the network what they're doing, absorbing information and show that. It's the network source of truth. Now I'm sure you heard that before. What does it mean in this case? All configuration targets are done in the orchestration. The network constantly audits itself and looking for a delta between the target and the actual. If it's a read-write, if there is a delta between them, it will override the change. So if you wanted the following config and somehow some of the access that switch and change something, it will override the change. It will do that every few minutes. If it's a read-only mode, we will show you the background of that switch would turn brown and say I have a delta between what you want me to, your intent and the actuality. We show you a lot of statistics on everything going on, on a port level, device level, network level. Everything is graphical. What it takes to build a network. Like I said, you can do multiple ways. In this case, we show a CSV file, really basic things. We, based on 13 different best practices, create the whole fabric for you. You can go ahead and change and say I don't like that ASN, ASN numbers. But we will assign VNIs, VRFs, everything automatically. So for some of you, you don't like, some would say, oh, my goodness, that's terrible. Others, the majority actually will say, we like it. So here's a video. We have a customer who did a proof of concept, 10 switches, Dell hardware, three spines and seven leaves. If anybody wants a demo, we can do this after the mini-summit. I'll show you this. But this, basically, we created a digital twin of this fabric, 10 switches, all the configurations are in the system. One thing is missing is hardware. So what we want to show you, the counter on the top right, we'll show you. This is where we started recording it. And basically, you could see the controllers are starting getting instituted and start talking. And we'll then later on start talking to the physical hardware. So the hardware now gets the configuration from the target. And you start seeing it, oh, green, I start that. If you see that greenish background for the switch, it means it's getting provisioning. It's like, hey, I'm getting some updates. And you can see now, all of them are white, BGP established. Let's say you don't know anything about Sonic, anything about networking, just a guy from this free to pick up right now and say, what do you see? Is there a problem? And they would say no, right? I mean, you could see the fabric is basically fully established and that all within 30 minutes. So to set up the network will probably take, 20 minutes, 30 minutes for somebody who knows what they're doing about networking. And then a rack and stack. This is out of my realm of expertise. So I don't know how long it will take to a rack and stack 10 switches, but then bring them up another half an hour. So within a less than a day, you can create a fabric fully operational running Sonic. It's key to mention that in the world of edge, migration and multi vendor is key. Your CFO might willing to spend, you know, millions of dollars in data center, but come try to get like, you know, a few thousand dollars for, for the campus. That's a major struggle. So they want to squeeze as much as they can equity for that switches. So you will have to have this migratory technology to able to that. And you know, this is us. Any questions? So the question is that basically on the scale, right? What is the scale that you're targeting software stack at for? We have several PS POCs with the hundreds of switches, you know, for data center, but in the edge, we have one network with 4,000 switches in one local air network, 4,000 switches. So scale wise, we really don't have a limitation because the orchestration platform is one VM. And then you can have one too many approach. And then you have another VM of the control layer that can have that control a few hundred switches, but you can have multiple VMs. So scale wise is one too many. So we can, you know, I don't recommend people to put in 10,000 switches in one data center, all in one orchestration. But that's, by the way, we support MC lag, all the things you talked about, you know, the challenges, we know that the test and the tried, we run out of real equipment. So we know some of the challenges that you had. Yes, sir. Let me see if I got the use case right. So for example, you're claiming that you can have, for example, a fabric with Cisco devices. And then you just put, get one of the Cisco devices out and put a sonic switch and it will work like automatically. Because as very similar to what Susie Q does, we have a container in our orchestration that talks the specific language to that switch. So through LDP, we know it's Cisco. So we can we write to it as a search to it, and then we write CLI commands, our orchestration, write the CLI, not you. So when you put a command in the orchestration, it will translate into the controller, which will push that into the Cisco. For Sonic, we do GNMI. So same command on the orchestration and create, you know, BGP creators will be followed throughout and through us, you will know to channel them. So that's how you can now, that's how also you can take that Cisco switch later and just say, oh, you know, put in associate this configuration with a new sonic device. So once you plug the new sonic, it will automatically configure it in the way the Cisco, because you had the running config, we take it, we translate it internally to write it into the, to the Sonic switch. Asking on behalf of the community, what are the most desired and popular scenario for edge, that in addition to this management system, right, I see that orchestration is much needed UI with a visual, like looking at the data. But how about other scenario that you have seen that all when you talk to the customers that the most popular or desired scenarios they are looking for? Yeah. I think the biggest challenge of Sonic in the edge is actually it's enormity or the comprehensive NOS. It's a big one, which means I cannot run it on cheap hardware. So, you know, what Sonic needs to do is to slim down a little bit or not a little bit a lot to make it that because what we see in the edge, you also have, you know, you talked about, you know, you do on your fabric only layer three. And the edge is that's not the case, because especially if you're running a small edge with SD when you cannot have like layer three from that switch, you need to go through that. So, you know, there's different use cases for the edge, but the edge is the next frontier, right? You took care of Microsoft took care of the cloud, right? You know, you made it so powerful, you can scale it, etc. But, you know, what we see there now, hungry applications are coming into the edge. For example, VR and AR. And I don't talk about metaverse, you know, I'm talking about real work, like people, you know, remote technical support, etc. Those will fuel some applications that Sonic can run, you know, run the aggregation of those points, you know, IoT is another thing that is going to explode. So, yeah, so we as members of the Sonic will push, you know, edge use cases. You know, I, Surab Kapoor from Dell is not here, but for two weeks I was in his head in his ear, like, oh, you guys have to do this lower, lower end, you know, like, and, you know, so I talked to Broadcom and in Prague as well. So we are big supporters of this. Well, thank you again for the Sonic community.