 Well, good afternoon. Thanks everyone for coming today. My name is Michael Lane. I am a technical program manager in the networking division of Amazon. I'm actually in the physical stores division. So physical stores, they're the ones who are developing all of the low-end switches, not the high-end data center switches. So one of the things we focus on are really the enterprise use cases and the edge use cases. So that's why we're going to be focusing a little bit on the enterprise edge open source operating system. For a little bit of background on myself, I've been at Amazon for about now going on 11 years. I was in AWS for eight of those years. And for the last three years, I've been part of the physical stores division, which recently merged back into AWS. So I'm back kind of a bit of a boomerang into AWS. So one of the things we wanted to talk about today was DENT. So let's just first kind of set the ground here with what DENT is. So DENT is not just an operating system, but it's a whole ecosystem that includes software, it includes hardware. We have a number of manufacturers. We also have some silicon providers. So it's not just hardware, and it's not just software. It is everything that is included from even testing. The testing methodology that we're leveraging is also part of the DENT ecosystem. This started out as a Linux foundation project. So we started about three and a half, four years ago in the Linux foundation. And then we've continued to work not only in Linux foundation, but we've also done some work in the Open Compute project as well. So you'll see later in the slides where we've kind of started to do that crossover between the two and a lot of collaborative work between the two organizations. We are very much technically focused on the networking solutions. So you'll find that a lot of the talk that I'm going to be speaking on is really around networking solutions. But it's not to say that the DENT operating system couldn't be applied in other use cases. Some of those use cases might be edge gateways or perhaps RF gateways, some places that we're also using those as well, or in IoT devices. The other thing is part of our mission is to promote participation. So you will see a call to action at the end to participate in the DENT Linux foundation working group or the whole project. And you can do it in a number of different ways. One is you can become a member of course, but also just attending the TSC. And also we just started, we just formed about a month ago an end user group as well. So this is something where you can voice your features, your use cases to help us build a better ecosystem. And then finally providing a neutral home. This is one of the things around developing a community organization, open source organization is having a neutral place. So especially when you're talking about multiple suppliers, whether they be ODMs or they could be Silicon providers. So we want to make sure we have a neutral place for each of them to develop and co-work. So let's just kind of go into some of the things that we are working on today. Some of the key elements, starting at the top Linux, the DENT operating system is a Linux based operating system. It uses switch dev and now most recently we've introduced SI, so the SI is the switch abstraction interface and that's an OCP driven project. And then it also involves the Silicon manufacturers. So we have multiple Silicon manufacturers here, a couple listed, we have Marvell. We started with NVIDIA, I guess it was Melanox at the time who's now NVIDIA and they're more also working with Broadcom today as well to pull into this ecosystem. From a hardware perspective, not only are we doing, you know, just, we're not just doing routers and switches, but we're also looking at expanding the ecosystem into cameras and sensors. So in our use case in the physical stores, we also have DENT running in some of our pedestals in our entry exit gates. We're also looking at expanding that into some of our gateways in terms of, these are RF gateways for sub gigahertz. These are like electronic shelf labels and for some of our shelving units that are running at sub gigahertz. All of these run on a DENT operating system. And then software, of course, our networking OS, our telemetry, our configuration and provisioning. As you can imagine for us at Amazon, a lot of these are very much cloud based, but it's not to say that it couldn't be portable to another type of cloud, whether it be Azure or Google or a cloud of your choice. We just happen to use it at Amazon. We just ride on AWS as one might expect. And then of course support. You know, this is the developers, end users, testers. We have a really strong partnership with Keysight. You'll see that they're listed here too. Keysight has been very pivotal in developing a lot of our use cases and housing a lot of our test beds so that individuals can actually go there virtually and test a DENT operating system. They can test a DENT topology or a network based upon a DENT topology. So these are types of things that we're working with within the community. So a couple of things, let me dive directly into the operating system itself. So first of all, the operating system is built on Linux. So it is your flavor of Linux. Some choose different types of Linux, but it is very much so a Linux based operating system. So from a user's perspective, it looks and feels like a Linux device. Okay, so it's not gonna have that shell that one might be accustomed to with some of your big iron like Orista or Cisco or Juniper. It's gonna have a much more server-linux-like user interface. It is free to access the source code. So that's one of the things that we leverage is the source code is free to download. There are no barriers in terms of pulling things down or installing the binaries directly from the DENT website. So we have a lot of users who want to trial the DENT hardware. So we're able to connect them with some of our ODMs that we're partnering with and they're able to just download straight off of the GitHub the DENT operating system and build it themselves. And then some of the benefits, I think these are pretty common across the open source space quality. We have automated test beds that are developed in-house and they're run by Keysight. So we actually have a third party who runs all of our test beds. They run all of our regression testing. We also do the same internally within Amazon. And we provide, we actually upstream all of our test cases into the community. So we're developing more and more cases as we go. And then cost, oftentimes when you're working with big iron you have to worry about costs. So here the cost for pulling down the software, leveraging the software is free. Now there are other costs of course and that is managing your own network and managing the resources but we all understand that those costs are your own internal operational costs. And then finally, being community-driven, open source, as an open source program it is community-driven. We get a lot of feedback. There are users that aren't listed on that previous slide that have provided a lot of really valuable feedback in terms of what features that we are, that we should pursue. So some of those features, I'll show you what we have today in terms of features. We started off releasing Dent 1.0 about two years ago. And with Dent 1.0 it was primarily for the Amazon retail business. So being the first customer, Amazon retail needed some of these features developed. So what you'll see over on the left-hand side are the initial features that we released with Dent 1.0. There might have been a couple of features around policing as well. The first few features we also released with Dent 1.0 as well. But as we matured, within one year after releasing Dent 1.0, we released Dent 2.0 which we added more robust features around Apple management, improved firewall. So one of the things that we found was scaling became a little bit of a challenge. So working with our Silicon providers and working with our developers, we were able to scale a lot greater than we did initially. And then also we added a PoE controller. So Power over Ethernet is pivotal in the enterprise space, at least in our space because we need to be able to power cameras. Even our gates, our entry-exit gates are all powered over Ethernet. So we needed to establish an ecosystem around the PoE. And this was a little bit of a challenge because we had to not only do it that was Silicon agnostic, but also we had to make sure that it was hardware agnostic as well. So we could leverage the same controllers whether the hardware was built by Acton, Edgecore, or DNI, or Wistron, or other ODMs that we leveraged. And then we also included some of the port isolation features in version two. This was important. We had one customer, the DoD, had stepped in and said, you know, some of the things that we want to do in our network in leveraging Dent was some port isolation and even port mirroring. So these are new features that we added as part of the Dent operating system in Dent 2.0. And then finally, our last part of Dent 2.0, which was again released last year, we added dynamic routing support via FRR for BGP, OSPF, and ISIS. Now, we continue on a pretty much a annual cadence right now. That's kind of how we've established ourselves in delivering new features for our customers. Now, with Dent 2.0, at least for the Amazon side, we were able to provide sufficient features that we didn't really have to go into a Dent 3.0. However, we were looking after the entire ecosystem and looking after other customers, prospective customers who might want to leverage Dent in the enterprise. So we added a few more features. One of the things here in particular are early access to things like 802.1x for authentication. So this is something that we had not only internally within Amazon, we had our fulfillment centers. They're like, well, we would love to use your operating system. However, we also use 802.1x for authentication within the fulfillment centers. So we've added 802.1x as a new feature in 3.0. And by the way, 3.0 was released only about three weeks ago. So we've actually delayed the release a little bit because we wanted to do some extensive testing both internally within the Dent community as well as at Amazon. Even though some of these features aren't actually implemented in our network, we felt it was prudent for us to go ahead and verify some of these features ourselves. QOS is an interesting one. So in our use case, quality of service is necessary because we have very costly WAN links to each of our stores. And if you think about retail stores in general, whether they be a Starbucks or even a small store like McDonald's, oftentimes they're constrained by the bandwidth that goes down to their store. In our use case, we're not necessarily constrained by the bandwidth going down to the store, but the bandwidth going up from the store. And why is that? Well, we have all this AI inference, all these cameras that are doing all this work that is actually being done in the cloud. So a lot of these workloads are being pushed to the cloud so that the cloud can do a lot of the inference. So we implemented quality of service and right now we're in the process of rolling out quality of service internally within our network. And by the end of this quarter, by the end of June, we will have quality of service rolled out across all of our fleet within the physical stores. IGMP snooping and then egress policies, we enhanced a number of the egress policies. This is something that we felt was necessary, especially from a firewall and security perspective. Now in terms of the current state of dent, now up until now, dent has been very much kernel driven. And what does that mean? It is basically uses switch dev and the TCP IP stack and the networking drivers inside the kernel. So this adds for a lot of stability because the kernel itself is well maintained. However, it can get rather tricky because onboarding a new vendors SDK presents its own challenges, sometimes around IP, sometimes around limited developers because then you actually have to work with Marvell, you have to work with Melanox, you have to work with Broadcom directly to write those drivers into the kernel. So it just didn't scale, as we're looking at more and more silicon providers, it just didn't scale. So the community also had to respect, in some cases, they're the silicon providers SDK. You can't just upstream the SDK. You obviously have to do it in binary format and then there's a lot of things that you need to consider around uploading things in a binary format. So what we did is back in October last year, we started reassessing what is the right model for us to develop software in a more modular fashion, allowing more silicon players or silicon providers to play within the ecosystem. So this is where we moved to PSI. So for those of you who don't know what PSI is, PSI is the switch abstraction interface. This is a project that's actually under OCP, but you have other organizations such as Sonic who highly leverage PSI for all of their communications to the silicon directly. So what we're doing is we're leveraging a similar architecture for DENT, though it's not quite as heavy as the Sonic architecture. So in another slide, I'll show you a little bit more about what I'm talking about there. But one of the things we wanted to leverage is we meet regularly with the Microsoft team and with the Sonic team. It's kind of advantageous being that they're only a few miles away, that we can just go over across the lake and we can go visit with them and we can actually have sit-downs and one-on-ones with them to talk about how do we build an ecosystem together around PSI? Allowing the Sonic community to really focus on the enterprise from a perspective of the data center. So they start at the data center and they work their way out. Whereas DENT is kind of looking at it from the edge and working their way in to the enterprise. So we will come together at the enterprise and I think this is where we give the opportunity for customers a choice. Do they want to run a Sonic operating system or a DENT operating system? I don't necessarily see them as competing. I think that this is an opportunity for the two organizations to collaborate and now that we're both in the Linux Foundation, we actually have the means to collaborate in a neutral space, that being the Linux Foundation. So one of the things we wanna do is by leveraging PSI, we're working more closely with the PSI community to enable enterprise features. Some of those things such as 802.1x that I mentioned before or even quality of service may not have been in the PSI that is used for Sonic. So what we're doing is we're enabling those features in the enterprise space. So one of the challenges we're also having is in the PSI community is really getting the right players on the enterprise space to be represented. So a lot of times PSI and Sonic, people kind of think those are synonymous, but there are actually other operating systems that are running on PSI. FBOSS, for example, from Meta, they're also running on PSI. So we chose this more neutral approach and still an open source, open community approach allowing us to actually intercept more silicon. This opens up the door to beyond just Marvell or Melanox or Broadcom, but not even Cisco Silicon One. And some of the other silicon could be very interesting in the enterprise space. So a little bit about the architecture. So the architecture itself starts, kind of the PSI is the HAL. It's the hardware abstraction layer. And we're working very closely with a couple of partners in Romania to do the software development. Amazon's really focused on doing a lot of the integration work with our hardware, but then we also have a supplier in Romania who's doing a lot of the software work, a lot of the heavy lifting. And we've also worked with some of the other software developers also in the Eastern European area, specifically on PSI. The advantage here is that you have a lot of developers who are already familiar with PSI. So this opens up the community even more. We're just opening up specific features that are enterprise ready. And then we have to go back and we have to do the validation. So one of the changes here, as you can see in this diagram is at the ASIC level, you have all of the hardware. And then that right now, it goes up to the available kernel, vendor kernel module, whatever that might be. And then we've added this other area called the Netlink switch dev driver. So since we're still running in switch dev, we're still running in Linux. We need to have this shim that we've developed so that we can talk not only to the switch manager via a PSI API, but also we're able to continue to work in kernel space. And then as we go up into user space, then we have, of course, we still have FRR, TCPIP and the TC applications, those things remain. But what we've done is we've enhanced both the Linux switch dev driver, as well as the switch manager. We've created this new interface or new shim so that it can talk directly to the ASIC. So some of you might be familiar with like a LibSci and this is very similar to what we've done here. We wanna create this so that it is agnostic to each of the vendors. However, to be honest, we're having a few problems there. So the SI interface was intended to be vendor agnostic. However, we do understand that there are nuances with each vendor, each supplier. So we have to take those into account. Okay, and I think in the Sonic community, they're realizing very much the same thing. You have a question? So we have both dotted interfaces. We have the one down here with the netlink switch dev driver, okay? So that one is pretty much what we've always had in the past, you know, in switch dev. But what we added was this switch manager up at the top, which is in user space. Yes, that's exactly right. Yes, yeah, the intention here is to abstract everything away. We're kind of in this interesting phase right now, because all of our up to version 2.0 and even version 3.0 was all written natively in switch dev. Right? Switch dev is at the kernel layer, right? Yes, it does. Yep, yep. And then what we've done is we've created this in the user space, the switch manager, which basically talks to PSI, right? And then also talks to our switch dev layer as well. Yes, yes, yep. So it is a little bit complicated too, because just for a little bit of context, the native dint actually requires two CPUs. One is a firmware CPU, and one is a, which we consider kind of a control plane CPU. And the other one is the primary CPU. And that's basically due to the architecture of dint. And the thing is, is when we start talking to some of our suppliers, it actually is much more expensive, obviously, to have two CPUs running in a switch. So what we're able to do now is we're using the term trampoline is basically use a single CPU using PSI, okay? So that we're able to use a single CPU and run the switch in just a single CPU mode. The advantage here is that when you take a Marvell CPU, or a Marvell ASIC that has an embedded SOC, I don't have to install another CPU on the main board. Actually, yeah, so we will no longer be developing any new features in native switch dev. Yep, all new features will be going, will be developed using the PSI model. That is one option, yes, that we could use that. Yeah, so the CPU, and that's one of the things, in the architecture, and I don't think I have a diagram of a typical switch architecture for dint, a block diagram, the old versus the new, and I think that's probably something I can add in future slides. But the architecture up until release 3.0 required two CPUs, and with the new architecture running dint, we're moving to one CPU, primarily for cost, but the other reason is we just don't, we realize that we don't need two CPUs after all. We do use that CPU for some of the user space applications, but what we've found is even some of the CPUs for Broadcom, for example, may not be powerful enough. So the Marvell CPUs, for example, is a dual-arm core, and the dual-arm is actually sufficient to be able to run dint operating system as well as local agents. However, the Broadcom, at least in the Trident 3x2, Trident 3x3, they have a single-arm core, and it just isn't enough power to actually run a switch. So you might have, we're looking at how we change the architecture. Yeah, so that's an interesting thing, how can you run containers on dint? Yep, yep. So let me, I'm going to actually jump beyond my call-to-action slide, and I'm going to show you something that we announced a couple of days ago from a hardware architecture, how exactly we're addressing that space. So, let me just jump a couple of slides. So a couple of weeks ago at OCP, we announced the Enterprise Edge Gateway. Well, the Enterprise Edge Gateway is exactly intended to do what Amir was asking, is the Enterprise Edge Gateway actually has a slot for a second CPU. And this is a Kami-based CPU, so you could use that for containers, you could use it for firewalling, you can use it for any user application. It doesn't have to be part of the actual switch NOS itself. You can still run the switch NOS on the embedded CPU, and then you would have this type of device, and I'll show you real quick the hardware specifications. So some of the hardware specifications include, and this is just a mock-up, so this was again submitted only about three weeks ago at OCP at the Regional Summit. And the intention here is to have a PoE switch, it could be 24 ports, it could be 48 ports that runs not just PoE, but it could also run Wi-Fi, it could run LTE modem. So it's a modular type device, but it also has that Kami module, and you'll see here on the second bullet down, it says PoE support, and then Kami CPU module, that could be an Intel-based, it could be ARM-based. We're starting to play now with some of the Intel Denvertons and some of the ARM, the NXP arms to develop new Kami cards specifically for this box. The workloads that we're specifically looking at are things like containerized, we call it EC2 Anywhere, right? So for AWS, we would leverage it for EC2 Anywhere, but it could be any Kubernetes, it could be any containerized workload that you want to run on it. The other thing is you could actually run this as a Sonic box as well. Currently, Sonic requires a second CPU based upon their architecture, so this could be a Sonic-compatible box as well. So this is again why we're moving towards a more open hardware and open software approach so that both communities, the Sonic community and the Dent community can leverage similar platforms. This provides customers a great opportunity for choice. Also, this isn't necessarily just a retail box. This could be used in telcos. I've already had conversations with a lot of the telco community. They may not like the form factor. Some of them might say, hey, we'd like to have a desktop form factor that they could actually deliver to a customer. So these are types of things that we're going to start taking a look at. And I'll be working with a lot of the ODM partners. I know that there's some ODMs here in the audience today who I'll have some conversations with around how to create this box that might be more user-friendly or home-friendly. Price targets. I would love to see these price targets for a box like this fully loaded, probably about under $2,200. That would include a Wi-Fi module, include an LTE module and a Commi board. Base model probably would run around $1,500 just for the base. And then when you start adding the Commi, that's another $300. Wi-Fi is going to be another $2,250. LTE is going to be about the same, maybe about $200. And we're working with Wi-Fi partners. Specifically, we're working with Qualcomm on some of their chipsets, both for the Wi-Fi side as well as for the LTE side. This could also be used in your home office for something like you can add storage to it as well. So there are enough slots, enough lanes coming off the CPU. You could actually use this for some local storage, caching storage as well. But I wasn't planning to show these two slides, only if time permits, but I think we had the right audience, the right questions around where we're going. And as I said here, it is going to be multi-sourced from multiple providers, but also the intention is for it to be able to leverage multiple operating systems. Dent, if you want to use this in an environment where it's strong for retail. Sonic, so there might be some Sonic users. I know that I have colleagues over in Alibaba who have deployed obviously a very large Sonic deployment all the way down to their retail sites. So this is a really great opportunity to leverage a common box in their retail stores. So these are types of opportunities that we're going after, and it's just a matter of putting things to paper and really getting those out there. Yeah, another question. It could. I mean, depending upon the Sonic architecture, the hardware itself can support multiple architectures. So given that this is running Oni, much like what Sonic runs Oni as well. So from a base layer, from a boot up layer, it can choose whether it runs Dent or it could run Sonic. So it really doesn't. It is all a matter of how you leverage the hardware to be able to run the different software applications. Yes. That's right. It's one or the other. So I think Amir should probably come up and probably give the rest of the talk. But Amir actually saw my talk at OCP as well. And we presented this as a keynote, this particular device. And it's one of those where Amazon coming to the table and showing, hey, we're really innovating in this space and we're really thinking about it. But only that, we want to also open it up to the community to help develop, co-develop these. Like I said, we're working with Microsoft on the side side and they're going down the Sonic path. We're going to go down the Dent path. But we do have other retailers. There are big retailers in the Pacific Northwest. There's a big coffee retailer that we're working with. We'll just leave it at that. So these are great opportunities. And I will go back to the call to action slide because we're right at the top of the 40 minutes. And this is something for you to take away with. On the Dent side, I absolutely encourage you to go to the Dent.dev. You can learn much more about Dent. Learn all about what we're doing, how to get involved. A couple of things there is we do have regular TSC. This is the technical steering committee meetings on Wednesday mornings at 8 a.m. Pacific time. And then we just started the end user group. So the board met two weeks ago and we voted to have an end user group and that coffee, that green coffee company that I referred to was our first end user. I'm sure that they will announce it publicly when they can. But we encourage others to also join the end user group because we really want to hear your feedback. We also have a demo pool so that if you want to try things out, you can either do it virtually that's hosted by Keysight or you can actually get some hardware from us. Amazon is holding some hardware that you can use for demo. And then I need to also cross market, you know, OCP because PSI is part of the OCP organization. So I do encourage you to take a look at what we're doing in the PSI. I'm also the co-chair of the Enterprise Connectivity Solutions or ECS Working Group over in OCP. So we focus on enterprise solutions and the box that I just showed you, the Enterprise Edge Gateway is the second submission from the ECS Working Group team. The first one was from Target, from Jeff Strandy, from Target who provided just a one gig switch, just a basic one gig switch and a basic 10 gig switch. But this one provides a little bit more functionality with the Enterprise Edge Gateway. And then finally, you know, I have that last bullet and this is really a call to action, also kind of a side to some of the ODMs. We do have at least four ODMs who are planning to have that box that I just showed you available for evaluation, probably about the end of Q4 this year or Q1 next year. And I'm more than happy to help coordinate that. You can also do that through the DENT organization. But I'm really super excited about, you know, where we're going with DENT, kind of the transformation that we're going through right now in adopting PSI. It's not easy, I'll be honest with you, but we feel it's the right direction to pull in the right level of developers and also have a common platform that we can leverage with the Sonic community as well. So I think I am out of time, but I do appreciate the questions and I'm available afterwards for additional questions. So I want to thank you very much.