 Great. Hi everyone. Welcome to the dent workshop. We'll maybe give like 60 seconds for folks to connect and we'll figure start it. Maybe give a couple minutes. So we'll start in like four minutes past. Yeah, it looks like folks are dialing in. Okay, for those that are just dialing in, we're just giving another minute or two folks to connect and then we'll get started. Great. Okay, hi everyone. Welcome to the dent workshop, sort of introduction to the dent operating system. As we kind of coined the term switch to the rest of us. With that, I hope everyone is staying healthy and we look forward to doing this actually at some point in person. On this virtual stage joining me today is we have Rupa Prabhu, who's the media and previously the chief architect at Cumulus Networking and has background in kind of networking. We have Steve Noble, senior engineer at Amazon. He's the TSC chair or the technical steering committee chair for dent. Steve's also the president of NetDeaf, which is a non-profit which provides services to the FRR community. Both Rupa and Steve are early adventurers in the Open Networking switch step, sort of bare-metal switching revolution that we're seeing these days. And I'm Trishande Landryl, the links foundation and the technical program manager and community architect responsible for sort of the layer-to-layer three projects, including dent and DPDK and FIDM. With that, welcome. We're here with to introduce sort of a new project that is just not going to be announced back in December at the Linux foundation called DENT. It's a open NAS for networking sort of focused at the campus edge, remote office and branch office with initial use cases as a focus on the retail market. And we're trying to do this with a new NAS sort of the Linux kernel way and we'll go into that detail in the presentations to follow. As we said, we are sort of at the beginning of this journey for DENT and we're looking to engage with the community and grow a vibrant community around it. And on that today's program, we'll sort of take a look back, see how we got here with the editing of the history, the networking project, we'll introduce you to DENT. We'll talk about switch there, the next kernel switching that we've built in. We have a live demo for you with the code. I hope to run this live. That's always an adventure and a risk to do that, but we'll try. And finally, we'll talk about how you can get involved in the different ways you can participate in the DENT project. With that, I'll hand over to Steve. Hello, everyone. Steve Noble from Amazon. So most of you are probably experienced somewhat in what open networking is. It's been going on for over a decade. Realistically, probably quite a few decades, if we think about when we were using Linux boxes with Nix in them as routers and things of that nature. But the real value to open networking today has been the ability to replace legacy vendors, Cisco, Juniper, vendors who didn't offer options. For example, if you needed to get a fix for a feature, you had to request it from the vendor and it might take six, 12 months or you might not get it. But open networking would allow for you to fix it yourself or to get a community fix or pay somebody to fix it, really makes it a lot simpler. So I kind of use Pronto, which is a part of Quanta as one of the early open networking companies. And they started producing switches for some large vendors who were looking at options. And then Acton, Edgecore and Quanta both started producing switches in mass. We started seeing things like the Acton AS5712, which is by far one of the most used switches out there, at least from the standpoint of labs and doing open networking testing and things of that nature. Oni, which came from Cumulus Networks, was a huge advancement. Previous to Oni, you actually had to burn the software directly onto the memory card and put it back in. So I remember historically taking switches apart, taking the memory card out, putting them in another system, writing the file system, then putting them back in. And Oni allowed for the ability to install, uninstall, reinstall your operating system, which made it amazingly easier for people to be able to to do the work. And then I point out ONL. I was the public lead for the ONL project for about five years when I was at Big Switch. But ONL came out and just provided an OS, a network OS for the switches. So hardware, software, desegregation, networking. So as we know, enterprises and data centers have been proprietary from the silicon to the hardware, the operating system and the applications. With Linux, it allows the standardization of the silicon and the switch, and it enables the creation of a network operating system and applications. So here you see on the left in gray, the network OS running on top of hardware. And then in green, we have desegregation, which is the network operating system really has a very small attachment to the hardware. It's more open and it's able to be run on multiple systems allowing for a more consistent view across the board. And then technically providing abstractions. And so you can see there on the right, the most important part about all of this is that we're able to do both infrastructure abstractions and hardware abstractions, and then provide a unified API to the applications. So software is a bit out of order, but initially what enabled open networking to happen were that there were open SDKs or APIs provided. And one of the first ones was OFDPA for open flow, which then utilized floodlight as a controller and a tool called Indigo to allow for intercommunication. We also list open NSL inside there. They did come later, but they were part of the base. Without these, it was almost impossible. To have open networking. So start seeing open flow controllers around I think 2008 or so switch dev was introduced. And then I think 2011 it started to gain its footing and become more and more within the Linux kernel. And it continues to be worked on significantly at this time. In fact, there'll be significant changes in the 510 kernel, which as some of you may know was announced to be the next LTS kernel for Linux. So we're very happy about that. And it's going to be very useful to us in our project. So post the switch dev announcement, we started seeing more noses coming on. We saw a sonic open switch and some other open noses. And they started to provide a more standardized view across the entire ecosystem. So instead of having a, well, I can use Fronto again as an example, right? Instead of having a Fronto switch with the PICOS OS on it, and then having an edge core switch with a different OS on it, suddenly you had the ability to run the same OS across all of these different systems. And then now we're basically announcing project dent. So this picture, a little complex, but the picture we're trying to get out is that within Telcom, especially with the release of Danos from AT&T, you're seeing better alignment and more push towards openness. And then obviously, the Linux Foundation networking project handles a lot of this. FRR is technically part of LF as is open switch. When we go to the cloud networks, the point that's trying to be made here is that if you look at the major internet properties, I suppose, you'll note that Facebook uses FBOSS and OpenR, and Google uses Stratum, and Microsoft uses Sonic, and all three of them use different SDK abstraction layers, Open NSL, P4, Psi. And so there isn't a standardization really across the data center networks. But the biggest, I suppose, group of people who are utilizing in the data center networks would be the Sonic users. And so we're attempting to actually fit into a different space, which is the distributed enterprise, which allows for smaller organizations and specialty retail and things of that nature to have an open operating system. And a big point to what we're doing here with dent is the dent runs on Linux. You don't have to have any special code. All the kernel modules are open source. And once you've built it and you run it, you're not limited to any particular things. You're not signing NDAs or SLAs with different organizations, and you're not putting yourself in a position where later it may cost you a significant amount of money and time to move away from a proprietary solution. Am I talking to this? Sorry. Yes. So were you driving, sorry, Trishan, do I drive the slides? How does this work? Or will you? I can drive it, just let me know. Okay. Sounds good. Hello, everybody. I'm Rupa from NVIDIA, Previously Cumulus Networks. Like Trishan introduced, I've been part of the open networking revolution since quite some time now. So all of what Steve said, dent is aiming at providing this completely open source distribution for NOS. And Linux has been doing this forever. Linux has supported hardware every new hardware is certified for Linux these days. The out-of-box experience, that's what dent goal is. So the project itself, why Linux and what are the guiding principles behind choosing this architecture is, again, out-of-box experience with hardware, just like how server world has worked. And switch dev is the core piece of the architecture, which is essentially trying to support Linux networking stack, hardware acceleration, like Linux has done before for Nix and smart Nix and NPUs, the same guiding principle. Basically, you have kernel supporting the hardware with drivers and a NOS or an ecosystem and operating system is built around that. And what this means is, again, switch ASIC hardware is treated like any other hardware for the Linux kernel networking data part. This simplifies abstractions. The Linux networking API becomes your API. There is no need for a new API. However, you dealt with your NIC networking hardware with Nix and smart Nix. The same thing applies to switch ASICs. It's just that now you're seeing a box which is showing you all ports of the switch as network interface ports. The goal is, again, for the project itself to unify the community of switch vendors, ODMs and OEMs and end users across all verticals under this particular architecture under this particular open source ecosystem umbrella. And it is edge first basically for distributed enterprise edge, but we see it expanding to enterprise data center because the architecture allows you and the ecosystem partners also allow you to do that. Next slide. This is, again, a picture telling you the same thing. Basically, under the Linux foundation, we believe that it will bring all the silicon vendors, ODMs, system integrators and users, manufacturers as well, under this Linux foundation project to build this completely open source full featured network operating system. Then founding members. The premier members are the founding members, as you can see in the top two rows. And then we have general members and also new vendors coming in. And all these vendors have obviously signed up for Switch Dev and supporting the hardware required for Dent. So Dent uses the Switch Dev driver. And I'll talk a little more on the Switch Dev driver itself in the latest slides, the architecture itself around Switch Dev drivers. But the idea is you use the kernel drivers for Switch A6, the Linux tools, whether it's your ETH tool or your routing tools, your debugging tools, whatever you used in your Linux server for your networking needs. All those apply directly. And the operating system abstraction for networking remains the same between basically its uniform between your server infrastructure and your networking infrastructure. And all underlying infrastructure, including the Switch silicon or whether it's networking for the Switch silicon or you know, networking for a NIC, all that is treated equally with the kernel. It's a uniform model and it's as you know, the Linux kernel is one single upstream project which caters to all of these hardware devices. So it becomes even the cross pollination and you know, about picking packages or tools between ecosystems, between server and switching or the network fabric becomes way easier with Dent. So having said that, so Switch Dev is a kernel driver and of course it needs ASIC vendors to actually submit the drivers upstream to the Linux kernel. And today it's Switch Dev drivers we have today are Marvel and Melanox. And there are others in the works. Dent again, Dent partners with other ecosystems. Obviously it is based on Debian. We'll talk about that a little more later in the slides. We do partner with Open Compute OCP project for hardware for ONI for ONL, which is the base for Dent. Next slide. So why Dent? Wide access to hardware. Dent will have its own and has its own developing its own ecosystem of hardware partners. So that and also collaboration with other projects like OCP brings in that wide access to hardware which is easily applicable to Dent. Support of existing Linux tool chains, which means that anything that you have in the Linux Debian ecosystem or Ubuntu or Red Hat becomes available for Dent easily. That also means that newer technologies that are being built or newer tools that are being built on Linux for servers, it just becomes available readily. Recent examples like NAT or MaxSec as the kernel gets features for all of these and the tooling is done in the ecosystem for whether it's software or hardware implementations, it just becomes readily available across the board for the network fabric and the server infrastructure. No abstractions, no extra abstractions that is no need to add another level of API for the network operating system of the network fabric. It's the same thing for your server and network. And of course, because we're not dealing with vendor blobs, it's a completely open source, in kernel driver, you don't have this additional time to integrate vendor SDKs and solve other differences. The upstream community actually standardizes. As you submit drivers, it standardizes on the API, it makes your hardware easily maintainable and extendable in the Linux ecosystem. Next slide. Thank you. So dent focus, I mean, all of us can talk to the same side, but really, the focus of dent is to utilize and expand SwitchDev and support related upstream Linux kernel community. We really want to accelerate the adoption of SwitchDev, DevLink, these other tools in networking so that we can get to a standardized base, where in general, most Linux based noses are using SwitchDev. And the way that we do that is by putting together this project and essentially funding and helping to bring the community together so that we can get the features that are necessary into SwitchDev for it to operate in the different spaces. We're looking to standardize the Silicon and Switch software. We talked about this earlier, and this is really to support disaggregations and accelerate innovation. And provide a open source nos reference implementation and applications that can be created to support the target market. So the phase one is the distributed enterprise edge. So here this is going to be your commercial, your commercial companies, your things like warehouse, specifically, you know, companies like Target or Walmart and things of that nature who have a distributed enterprise where they have a lot of different locations and they have a lot of pieces in there, a lot of IoT cameras, all of that inside the network. Phase two is to look at the enterprise data center. That requires some more features in order to provide, you know, a spine leaf type of a topology. And then phase three is to look at other spaces based on what we learn from the board. So Dent with SwitchDev, embedded Switch, right? Kind of a weird slogan, but it just works is essentially saying if you have a piece of hardware that supports SwitchDev, then you can run Dent on it. And being Linux, you know, you've already have this trust relationship with the kernel maintainers and with the distributions. And so you're not going through a lot of certification testing, you're not going through a lot of penetration testing, code review and things of that nature. And instead, you can focus on doing the features and the applications that you need. One time configuration. So you just configure it, use standard Linux tools and essentially just turn on interfaces and we'll do a demo in a bit. But basically just you just configure it, right? As we mentioned, no SDK, there's no SLA, there's no agreements with different vendors that may cause issues with your ability to add features or expand what you need. It's designed to be lightweight and have high software quality. Are we answering questions in line? Sure, why don't we do that? So we have a question from Mark here. I'll just read it out. Often the biggest problem with writing SwitchDev drivers is missing documentation so far. Can we expect that at least the project participants will provide documentation under conditions that allow open source drivers with at least one of them? It was impossible in the past. Yes, I think, yes, that is right. Kernel has participants like Milanox have been actually enhancing the Kernel documentation as well to make this easier. And there are external wiki pages and I'm sure the Dent wiki page will also have instructions on how to navigate integrating or building new SwitchDev drivers. It's a good feedback. Thank you, Mark. We have, Roman had a question, when Dent NOS is going to be released, or is it already? We're kind of stealing our fund a little bit so we'll get to that a little later in the presentation. So there's a follow-up question on real register level docs. So I think that also depends on the vendor. But if you are a Dent participant and willing to write drivers, I'm sure the vendors are willing to share specs. And this can happen in the Dent development forums. And one thing I'll point out with the addition of Marvell to the ecosystem, you have multiple references within the Linux Kernel to see how systems are added and how SwitchDev is implemented. And so I think that that's going to help other vendors as they move forward to be able to add SwitchDev drivers. Thank you for the questions. Keep them coming and we'll answer them as they come in. So your question, register level docs from Marvell. I don't think that there's an easy answer to that. But you are correct in general, it is hard to get certain information from silicon vendors without having an SLA or some level of an agreement with them. And that just standard across the board. But here what we're looking at is that, for example, Marvell has done the implementation for the Braceras switches, right? Mel Nox has done the implementation for the Spectrum A6, right? So if we're looking for things outside of that, and I've seen discussions on our mailing list about doing this with smaller chips from Marvell, then that does become a question, right? So our hope is that as we start to get open-sourced hardware, the hardware will provide you with a lot of information. Ah, embedded automotive. Yeah, so there's actually some other things that we're going to talk about later. And then there's a project that we're working with, which focuses on building a more embedded type of an operating system. But at the moment, dent is expected to be for switches and not really meant to run on other things. And as we move forwards, we'll go ahead and be adding new ones. Okay, so initial use case. So the initial use case is the retail edge. Technically, I could also say that remote office is within the use case. But right now, we're not focused on data center. And we're not heavily focused on campus. But we do have POE switches, which are useful in remote offices and campus numbers. So big picture. The focus area, right? Retail is going to drive the next major revolution in remote and distributed enterprise business locations to meet the next generation of consumer experience expectations, right? So that's that's a statement that basically says we see more and more automation, we see more and more tracking and machine learning and and different tools being applied to to networking where where we we need to have operating systems and switches that that can easily add features onto them, if necessary. And dense goal is is to provide a the generic operating system that can then be expanded to to fit the needs of the different organizations. I think people are seeing it, right? We're seeing a lot of interesting changes in retail, partly because of the the current pandemic. And this is actually a really good time to start looking at at how we're going to modernize networks going forwards, how we're going to provide differentiated services, and and things of that nation nation and things of that nature within the retail infrastructure. And so this basically came, we think at a pretty good time. We think at a pretty good time. So the critical piece to net retail networking. So if you look at any any large organization company, right, that any large stores, you're going to see that that they have thousands, if not 10,000 of cameras, CCTV. They're doing a lot of work with with trying to automate and utilize that information to provide feedback to themselves and track, right? And then almost everything at this point in a store has some label and handheld scanners and those things that basically would be used to to log what everything is. And in real time update, you know, what do you have, what do you need, what's in the warehouse, etc. sensors, we're seeing sensors everywhere from the obvious sensors, right? The the tags that go into the the boxes that that will cause alarms to go off if you leave the building to the sensors are used in the in the pause systems, such as weight sensors and things of that nature, if you're doing your own, what we call self checkout. You have a significant number of pause systems, whereas previously you were limited by the number of employees that you had who could run a cash register. These days we're seeing a lot of automation there. And so you have the ability to have more and then these stores are 1040,000 square feet, sometimes bigger. And and so these are the things that we're trying to address within dent. So it's kind of a list of the technologies that are behind the transformations, right? So digital cameras, electronic shelf labels, sensors, your HVAC, right? You know, monitoring the the temperature within the different areas of the of the building and making sure that that everything is what it's supposed to be, RFID, lighting, card readers, right? There's a lot of technology that that's that has previously been more of a hardwired proprietary system where we're now seeing this being replaced by generic systems that are being integrated using just IP transit effectively. And then there are applications, right? People counting, line estimation, these are very important and have become much more important now with the pandemic in that and that we're able to know how many people are in a store, how close are they? I think you guys saw a cool video from from a company where they showed how they could actually track people within a building and see if they were getting more than six feet or less than six feet from each other, they would actually light up different colored rings around them and things of that nature to help people have awareness of of where they are and what they should be doing. Grab and go sales, I think it's pretty much unknown that Amazon has done the go stores. And so that's part of this focus here is that there's a lot of technology involved in doing that with the go stores. And so we have a significant investment in hardware. And we have a significant investment in the networking equipment, which another part of dent that I don't know that we really discuss is is dent also allows to cost optimize hardware for the specific use case. So instead of using an off the shelf box from the ODM, you can actually use a specifically optimized box that that is really for just POE, for example, or for just general networking with without having the the cost of buying this from a major vendor. Demand sensing, point of sales, shift management, doc control, right, all of this comes together and provides you with a big picture and optimizes your organization. So here, we're mainly talking about, you know, a standardized operating system across the retail network, right, that there are so many pieces, and there's so much data that being dealt with today. In transit project product, right, knowing that's what's coming when behavior analytics in motion inventory, right. We have our switches, the gateways, IP cameras, access points. All of this is very important for there to be success in this growing retail space. And I'll turn it back to Rupa. Thanks, Steve. Yeah, before I just continue, I think there was a question about Timeless Linux on the Switch Dev. We do get that question a lot. That is to be determined. Actually, as you know, Melanox does have its own Switch Dev offering with Linux Switch. And Timeless Linux kind of provides that abstraction between Switch Dev and SDK based Windows. So there is not a huge gap between Timeless Linux, SDK and Timeless Linux Switch Dev, but it depends on demand of how many people want to deploy it with Switch Dev. But like I said, Melanox is a partner in the DENT project and they support DENT and they also have a switch their own Switch Dev offering, which is a DIY solution for anybody who wants to build their own kind of very close to DENT. So the DENT focus area, Enterprise Data Center. Well, my, as you know, the Linux API, Linux Networking in the Enterprise Data Center and Cloud. And that's where Timeless Linux is. So my background has all been in that. And what the story here is, you have a unified automation control of all your infrastructure, the servers to the network fabric. And since it's just Linux, you can use many of these automation modules natively, right? There is not much changes needed. There are Ansible modules for the Linux server, some of them that you can directly use on to the switches. And the picture actually shows you that the Linux switch is nothing but again, it shows the ASIC shows up as a PCI device that imports. That's how the Switch Dev infrastructure enumerates the system for you. And on the telemetry side again, since it's an open box, open Linux API, many of these existing telemetry solutions, open telemetry solutions just work. And you can have a common infrastructure between your server and network fabric. Okay. DENT architecture, driving a little bit deeper into what components are present in DENT and the Switch Dev driver and so on. Okay. So DENT again, open NOS for the networking edge, edge first. So which means that the requirements of the edge NOS like PoE and other infrastructure comes first. So Switch Dev is the core. The networking API is the core. Switch Dev is largely not really seen to the user, right? The user just interacts with the box or the Linux networking as he would do on a server. It's the kernel that abstracts all this in the layer called Switch Dev. Switch ports appear as NIC ports in the demo. We'll show how that really looks. And this is Debian based. ARM is another, the first architecture that it supports, but obviously Debian and ONL have support for other architectures. Open protocol implementations. Being an open source NOS, it's important that we integrate open source implementations and with the last few years in forward open networking, there have been many open source implementations or there has been a huge surge in open source protocol implementations. FRR is one of the, so DENT uses FRR and FRR as you know is one of the popular open source routing stack, which is an LF project again. It has support for UNICAS, BGP, OSPF, and then even multicast protocols like PIM. Recently it's also got BFT and you know VRRP and so on. And it is soon becoming the one stack protocol suite, right? With the increase in the number of protocols it's supporting, which is nice for the community. I myself have seen it grow with the last, rapidly actually in the last few years with things like EVPN and so on. Feature velocity through Linux native tools. Again, as soon as the kernel gets a feature, there are tools that are built, some by kernel developers and some by the open source community around building that ecosystem. And of course, there are all vendors behind it who contribute. So the contributions for all this come, I mean, the space from where this contributions come is suddenly increased. You're not just a NOS vendor or a NOS community right now that the community is entire Linux community. So the acceleration at which these tools are being developed or the velocity at which these tools are being contributed are rapidly increasing. Even the debugging tools for that matter, whatever is happening in the Linux community these days with EVPF and with Perf and so on, those become readily available. So yeah, that's one thing that surely excites me, of course. Next slide. So, Switch Dev. Switch Dev actually started a long time ago when, in a way, when Cumulus was thinking about it, when the vendors was thinking about it, applying Linux networking to Switch A6. Whatever we have learned from building networking or network hardware acceleration in the Linux community, applying it to other devices in your data center infrastructure or in this case, distributed edge infrastructure. So the thought of Switch Dev came long ago because it's very, when you're working on a Linux system, it's very apparent that the driver or the hardware support coming out of the box is critical. It makes things so much easier. So the seed to get Switch Dev or something like Switch Dev in the upstream kernel started like, say, nine years ago when we were all talking about it when many companies came together and we needed a hardware vendor and that's when Mellanox actually submitted the first Switch Dev driver. So subsequently, as part of this whole effort of supporting Switch Dev or the Linux kernel networking for these A6, there has been not only the hardware support enhancements but there has been support or work done in supporting offload, right, for routing hardware acceleration, neighbor bridging and BXLAN for BXLAN, especially for EVPN for things like that. So there has been tremendous support in the kernel over the last few years. And API, it's called Switch Dev because, well, as you know, in the Linux kernel community, you call a net dev is a network endpoint of a networking device. So Switch Dev, started with the name Switch Dev. So it's called the Switch Dev project. But it was soon, we soon realized that there is no need for another special abstraction layer in the kernel. This whatever abstraction that the networking driver or the networking stack provides for drivers existing, right, like ETH tool, like iNetline, CartiNetline, and all those, they applied to switch A6 directly. There is no enhancements needed. So there are still traces of the name Switch Dev in the Linux kernel, but it's not necessarily, it's not only the Switch Dev APIs, it's beyond that. That is all networking APIs actually kind of have a Switch Dev back into the hardware support set. One thing that did happen, which was new for the Switch A6 was a DevLink API. And DevLink is a tool that is now on every Linux box. It comes with the IP route too sweet. This is something that Meronox contributed early in the days. What the networking stack lacked was a tool that was specific to global hardware state, hardware state, right? So you could always query a single port state or you always had to go through a port with ETH tool, talk to the driver, and so on. But with Switch A6, there is a need for a global state, global resources, global hardware resource management, global tables. So there are a lot of complexities that come with it. So DevLink has given, DevLink Merge in the Linux kernel gave that API for extending it for many of these features or resources within the Switch A6. And today, as the DevLink API or Switch Dev offload APIs are being developed, they are not only being used for Switch A6, but they are used by Nick vendors. They're used by smart Knicks and so on. So it's in a way in the past four or five years, we have seen that networking API become much more stronger and much more inclusive for Knicks and smart Knicks MPUs and Switch A6, which is a great thing for the community actually. And as these, even the Knicks are getting more powerful, even the Knicks are supporting the higher speeds and so on. So many of the enhancements, like even the ETH tool, speed enhancements, port breakout enhancements, all that is applicable through your entire infrastructure and the pluses you get contributions from across the community. So this is a picture of the same thing, how the Dent architecture or Linux networking stack and hardware acceleration is laid out, right? You have the kernel, you have the drivers. The drivers is where the Switch Dev drivers come in and you have the Linux networking subsystem about that, which is the routing stack, whether it's a net filter, the net link API and bridging BX LAN, tunneling, all that is the network Linux networking stack. The Dent will also support ONL. Dent base is ONL, so it also supports ONL P drivers. If they're available, if the vendor is giving you Linux drivers, pure Linux Sisyphus interfaces, it works with that too. So it's just simple. The kernel, since the kernel can support it, that is open and it's available. The Sisyphus interface or the net fraction called ONL P, which comes with ONL. The tooling is all whatever, right? FRR talks to the Linux kernel data plane. That's all it knows about. It does not care about the hardware. All the tooling is the same thing. It does not care about the hardware. So what this does is it allows you to test your data plane for your control plane without the hardware and when the hardware is available, it hardware accelerates it. That's the beauty of it. And that actually accelerates a lot of development time, test time, and so on. So I've been in the center of development, many technologies right now for the data center enterprise. And it is a huge cost saving when you can actually test, switch data planes and test with the software and hardware data plane. And yeah, and the picture actually shows the drivers that are available and the drivers that are in the works and switch the hardware, switch hardware. Sorry, I was muted. So the initial release, this is kind of our focus for what we're going to release. Note the tentative date is Q4, so coming up shortly. End of this year. And we're actually expecting to have a second release pretty quickly, just because there's some features that we're going to need that are in the later in the 510 kernel that will require testing and things that just we can't get done before the time frame of the first release. So we're focused on the 5.6 kernel. We're utilizing patches that Marvell have upstreamed to the Linux kernel and patches that are being upstreamed. And so the goal of the project as Dentos comes out is that the code that's in there and the behavior that you see is the same as you'll see in the future because it's not specific code. We're not just writing all sorts of different features and adding things into Dentos that won't be in the kernel and in the tools. And Rupa made a good point that each tool IP route to these tools all evolve with the kernel. So every time there's a new feature put into the kernels, then there's going to be a new release of each tool and IP route to and the new features are going to be supported there. And so part of the Dent project is also to make sure that we have the latest versions of all of the necessary networking tools so that we can take advantage of these new features. Like I mentioned, we're looking at a twice a year release cycle. And the first release is basically matching up with Marvell's switched of community release. We have ongoing discussions moving away from ONL platform drivers and moving to more Linux native drivers. There's other discussions going on, right, about if moving forwards, Debian is the correct piece. And then that came up earlier, right, there was a discussion about using this for automotive and things of that nature. To get there, the system has to be much more embedded rather than just a generic operating system Debian plus platform drivers plus the switch dev implementation. Go to the next slide. So Dent is named after a character in the hitchhiker's guide to the galaxy. And so we've decided that the first release will be named Arthur. And our expectation is that these features will be in this release. LLDP, SSH, L2 bridge, VLAN aware, configuration persistence, zero touch provisioning, L3, L4 ACLs, we've standard on TC flower moving away from IP tables and ECMP, STP, VLAN trunking. We have not through them all, but there's also support there, things like DHCP server, which is very specific to what the space that we're going into, where this could be a store, this could be a small branch, and having a server and or a relay would provide significant value to people. Support for Ansible, some debugging tools, ETH tool, as we mentioned, and ETH tool doesn't come for free. You have to actually write your drivers, which in switch dev to work with ETH tool in order for you to get the expanded pieces of ETH tool. And then we have some initial scale numbers, 32,000 Mac, 2,000 IPv4 routes, 3,000 ACL entries. And then we're looking to have a rudimentary POE management tool that will allow us to monitor and configure some of the underlying POE hardware. So if people deploy these POE switches, it's not just a passive inline POE device. Things have gotten better lately, but it used to be the POE devices, if you plug them in correctly, they could get the wrong voltage, they could blow themselves out, right? So it's important that with a POE switch that you have some level of management and visibility. Go to V2. So V2, at some point, will vote on the name. It will start with B. There are some pretty cool ones out there, but pass that. So VXLAN. For VXLAN, we're waiting for the support from Marvell because we feel that it's important that VXLAN works across the board. There are certain things that could be implemented based on what Mellanox has in the kernel. Mellanox's switch dev implementation is much more robust, has many more features. And so while we expect that Marvell will start to somewhat catch up over time, we want to make sure that if you use DentalOS and DentalOS hardware that the features work across the board. IPv6, IPv6 technically works. There's no reason that it doesn't work, but we don't have all of the features that we'd like. For NAT, we're looking at any needs in switch dev for supporting that. ISIS, because of how it functions, also needs some work within switch dev. We're looking to use netconf open config. Some people may be interested in that. It's already available within FRR. PPOE, EVPM multi-homing, 801.X. We're trying to keep the features low in the next release, but still add features that are usable and important for our use cases. Next. So the DentalEgo system. You can see here, if you go to the top, you have ONI. ONI is the root of any open NOS at this point. And then we have Linux, FRR. FRR being the tool that will probably mostly be interoperated with, running BGP, OSPF, those features. We're currently using the Open Network Linux builder. We've heavily modified things to work for DentalOS and added significant features, new kernels, support for ARM64 platforms that previously we only had examples for using devian switch dev. Obviously, the Linux foundation is involved here. And we look at using Ansible for different configuration and for testing. So the CICD framework. This is maybe somewhat hard to read, but essentially it's what you would generally expect to see in CICD. We're building, at the moment, we build with Jenkins. And then we push code out onto hardware. We also do some level of virtualized testing. And then we have test cases that run for different features, regression, things of that nature. And we can go on to the next. So generic topology. Some of the things that we do, right, we're trying to match what we, Amazon, see as important features along with the community. What the community sees as important features. So you see things like bonds between the spines. And then this is a spine leaf access topology, right? And your access switches are running PoE and they're handling the APs and they're handling the cameras and things of that nature. And there's a lot of L2 going on in the access switches. And so that's another feature that we've been focusing on, to make sure that we're able to properly partition and keep the land separate and things of that nature. These are all things that should work, but we have to make sure that they work correctly with the implementations. And then see we have power cycles test servers, right? There's a lot of hardware in this scenario. Go ahead. So we can do a demonstration. So the demonstration, I'm going to run it off of my system and then we're going to talk to it, both Rupa and I. And Stephen, while you bring up this share, we had a question from Jan. Marvell switched to have community release refers to the drivers net, Marvell pressed a code submitted by plvision.eu. So that was a clarifying question there. Yeah, that is correct. I don't know the history behind it. I don't know if Steve knows, but I do not. And I lost that screen. Okay. So quick time check also. Trishon, how many minutes do we have for the demo? Please. About 10. So the community release, the drivers. Yeah, so that code is actually submitted by Marvell. So the first era drivers are coming from Marvell. And you can actually just search for like prestera. For example, if you go look at RC one for the five dot 10 kernel, you can search for prestera and you'll see what's in the kernel at the moment and what's expected to go in five 10. One of the cool features is going in five 10 that we're very happy about is next top groups, which is a feature that FRR five seven dot three started supporting. And without it, seven three didn't work on switch dev without putting in configuration to say to disable next off groups. But we're excited that come the five dot 10 kernel will actually be able to just run FRR the latest seven dot three, seven, four, seven, five on top of this without having to go in and make these configuration changes. So here in this demo, I have a system. This is a Delta DNI built arm 64 based platform using the Melanox chip set. So the naming context is the TX 48 10. So there it is. The X is Melanox and it's 48 10 gig ports. It's a bit different than many of the switches you will see out there because it only has 48 10 gig points. It does not have special up links 40 gig 100 gig any of that nature. It's just this and this again fits within the use case and it's cost reduced. It's significantly cost reduced from from what you would pay if you were running a switch that had the QSFP ports and things of that nature. So here I have a script that we're going to run though will run some commands on this box. And the first one is link show input Rupa. Yeah. So this shows all the ports. We've been talking through the presentation that your switch ports actually look at look like Nick ports. So basically IP link is a command from IP to do and this is showing the ports similar to your E zero the management ports. And this one like Steve says it has 48 ports. And for anyone who's wondering, yes, those are test max. We try not to burn max as we're going through EVT, DVT and really focus on only utilizing max within the systems that will be deployed or are heavily used within the lab. So we also have support for ETH tool. And here we have a switch port three, which is a fiber connection that is running at one gig. And this kind of shows the the flexibility of what we're doing. Right. So this is a 10 gig port, but I have a one gig SFP in it. So we're seeing that here. So we can also get information. And here you can see it just says driver is the L knock spectrum. And so as far as we're concerned, this is just another network port on the on the box. Right. This isn't something special that we we have to support it just it's a network port you use you'd have rules to control it. And everything looks like it does in on a normal Linux system. So ETH tool minus M, we're just providing more information here. The SFP module information. And this is using again, the ETH tool infrastructure in the kernel. There's also go ahead. Sorry. So this is the DevLink API that we're talking about earlier in the presentation. The help just shows you what commands it has. And this, this command has is being enhanced as we speak. It's getting a lot more support in the Linux kernel and current work going on upstream. And yeah, so this shows you the PCI information. So you don't necessarily have to use the DevLink command on physical is WP port representation. What this allows you to do is, you know, for example, breakout breakout particular port into four ports so that the name doesn't matter the port name doesn't matter here as long as you give it the PCI ID, it will do the work for you. We don't have an example of a breakout port here. Because it's all using one gig and 10 gig here. But that is that was the first API that went into DevLink actually. So resource, the hardware resources again, another example. This is showing the Melanox hardware resources how they represent their hardware resources. But the DevLink infrastructure in the kernel is very generic. It's a name value thing so that it gives some flexibility to hardware vendors to represent their resources. This is IP. It's very boring on this box. Mainly I have a server and Intel Nook that's hooked off of it for providing some some test capabilities and then an uplink to another switch. Yeah, the only flags that I would like to mention is you must have seen the yeah sorry Steve you can't go back but the RT offload and RT trap flags are actually tell you that you know the hardware is programmed to either the route is in the hardware and the trap is basically telling you that you know the hardware is programmed to punt the packet to CPU. So those are special switched up flags for routes that you can see. Right, and here this is E0. So this is the management interface. So you don't want traffic traversing the box from the management interface. And here is the offload. And then here we can see that we have a hardware monitor name. I think yeah. And so we can look here is our temperature input. Right, so this is all again just straight in in Linux. You're just pulling this data out. And so you don't have to special drivers or any of that sort in order to be able to pull this information. This for some reason didn't work. But that's the nature of having EVT systems. But sensors does work. So you can basically see what the what the temperature of the different parts are. And then the front panel ports. Also what they have. We can see the the board temperature. All of this the fans the fan speed. All of this is available to you just directly through Linux. And then that ends that one. And it's going to bring over if we'll fit onto the screen. So something I find interesting, which is that I also run dent on a Melanox box the 2410. Because it's the main difference is it's x86. But otherwise, everything else is the same. And so we we can look at the ETL minus M and things and see the type of data. And that's it for the demo. Let's people have any questions. So we'll go back to Tricia. I think the slides after this. Yeah, so so this I just thought was a really cool picture. I was racking up the different switches in the lab. And when I took a picture, it just looked really cool. But you know, this is hardware diversity, right? This is multiple vendors, this is multiple different types of systems and all available with dent running on them. Just some screenshots here of same commands that we ran. And this actually is a good segue. We had a question from Robert is what's the best way to keep in touch? Is there some technical mailing lists for the project? And that's open to the public. So that takes us to getting involved in the dent project itself. Just to recap, as we mentioned earlier, we're trying to build out this ecosystem of contributors and community members. So we'd like to invite everyone here to attend to participate in the community. The project is open. We do have open technical discussions that is the TSC meets weekly and they have open calls. It's open public. The way the project is structured right now, we have the governing board, which is sort of responsible for strategy, budget allocation, marketing, resourcing for the labs, policies legal. And and then we have the technical steering committee, which Steve leads, which is really focused on the technical direction of the project. And looking at it, we're also looking at cross project collaborations there. And is the developer's voice to the governing board, and they kind of co-equal parties in this project. And ways you can engage and participate in the project. As we mentioned, please join us on the weekly calls. You can subscribe to our mailing lists. I'll have the link just to the next slide. Like this, you're participating in this developer event. Hopefully next year, we'll be able to do an in-person, hands-on demonstration and workshop for dent. We're always looking for participation in the documentation, to contribute to documentation, testing dent on your hardware and gear and ASICs. If you find bugs enduring when you're trying dent out, please submit them so we can take a look at those as well. And one part we didn't touch on is we are looking at building out the testing infrastructure. As we mentioned during the earlier slide, as we built out the CICD, we do want to have sort of a continuous regression testing plan for dent, and that we built out as well. How do you participate in dent? We have the dent website. Please join us. You can register for the weekly TSC calls under the calendar in lists, the listserv, which is lists.dent.dev, which is our groups.io server. And the code will be available as the release comes out. Later this quarter on GitHub under the DENT project, as well as the documentation, which will also be posted on GitHub. With that, we have a couple of minutes left. We'll just open it up to questions. So feel free to post your questions. And if you'd like to get in touch with us, feel free to send us an email at participate.dent.dev. And we can write your question accordingly within the project leads. And I'd like to take this opportunity to thank my co-presenters, Steve and Rupa, for taking the time here to present to you as well. Thanks. So we'll open the floor up to questions. If you want to go audio, we could just raise your hand. We could allow you to talk if you'd like. That's easier. So let us know. And I'll just go back to this. So you have that information. We are sure calling. Let's open up the mic and let folks chime in if they like. I think we answered a lot of the questions that came in line during the presentation itself. So if folks have any other questions, feel free to send us an email and join me on the post on mailing list. If not, we'll be on the channel here for a few minutes. We have a question from Jan on the Q&A window. It's signed off by, it says PL Vision. I'm not sure why they signed off as PL Vision, but the people who are submitting patches are the people from Marvel that we have been talking to or collaborating with. Marcus, yes. The question is, will the slides be available? Yes, we will post that on Sketch as well, after this session. Yeah, I'm just curious about the PL Vision too. So maybe you should just check with Marvel on the next call. We're happy to answer any questions. You don't specifically have to focus directly on dent. It can be about SwitchDev. It can be about DevLink. It can be about how we see the future of things going on. Really, we're open. I would recommend if anybody is interested that they come to one of the TSC calls. They're on Wednesdays at 7 a.m. Pacific time. And they're relatively heavily attended. And in general, we have people speaking about specific projects. For example, this week, we had someone talking about open embedded and Yachto and the value of that so that we could look at that and have some options as to what dent could base itself off of in the future. So we do have a question. Do we think that SwitchDev is going to replace Psy, et cetera? Tricky question. So if SwitchDev gains enough support, if SwitchDev, for example, if Broadcom releases a SwitchDev driver, then it would be pretty straightforward for almost anybody to use it. And in fact, SwitchDev could go into any project that's using Psy now and support certain platforms today. But we don't expect to replace Psy. But you may see a Psy to SwitchDev interpreter or something like that in the future, rather than Psy being based off of different vendors' SDKs. Great. So I'll just take this opportunity once again to kind of thank my presenters today. And we have one last question. We'll maybe take that as the last question. From Dennis. I saw many L3 features, which appears to be in many focus of dent. Am I right? Are you planning to support further L2 features? Rupa, do you want to take that one or you're muted? Sorry. Yeah. So L2 features, there are quite a few in the list. If you see that there is basic bridging and actually the first thing that went into the marble driver was also basic bridging. There is STP and VXLAN, of course, is an extension of L2 domains. So VXLAN in the future. So yeah, there is no only L3 focused right now. It's both L2 and L3. Yes, I hope that answers the question. Yeah. IGMP snooping is in the kernel. So IGMP snooping will work. L2 ACLs will work. PVLANs, there is, you can do PVLANs with ACLs on Linux. So that's how it'll just work. But yeah, there is L2 and L3. Great. Is it overtime? Yes. Thank you, Rupa. Thanks, Steve. Thanks, Rupa. You're welcome. Thank you.