 Okay, sounds good. Hey folks, so today we're going to cover how to build Edge Clouds. I'm going to use Thompson Fabric as an example simply because I'm most familiar with it, but the lessons you're going to learn are going to be applicable to any other technology that you choose for your networking. All right. So what does Edge really need? Edge needs service agility. In other words, ability to seamlessly deploy things in remote environments, ability to reinstall them and upgrade them and do so securely because the last thing you want to do is to do a truck roll just to reinstall something that's sitting underneath a pile of sweaters. So you also need to have operational efficiencies. You will have a very limited compute footprint on the Edge, so you cannot afford to have a Fed control plane occupying 11 servers anymore. You have to compress things down yet you cannot give up on the functionality such as monitoring security or anything else. So you still need to retain the ability to perform all of those advanced functions, even though you're going to be limited on the hardware, power, space. One of the primary things that needs to happen on the Edge is security. I think this has been brought home by multiple hacks from multiple companies, but the companies can no longer afford to have a distributed infrastructure that is not securing itself. You also need to have a consistent operating architecture simply because if you have too many things going on across your entire network, you won't be able to manage it long-term. And then like I said before, doing a truck roll for a small device sitting underneath the pile of sweaters is incredibly expensive. So you need to have a zero-touch architecture, you need to have the ability to do self-recovering other things. So fortunately, OpenStack and some of the networking SDN products can be shrunk to fit into that space. So I know this is a really busy slide that's showing the typical Edge deployment, which is mid-tier central office, right? So this is not quite the pile of sweaters I promised. This is more of a half-rack worth of gear. And at that point an OpenStack in an advanced SDN start making sense. Okay, so what does Tonstone Fabric do to enable such an Edge deployment? Well, the Tonstone Fabric shrunk its own control plane. So the typical Tonstone Fabric control plane has multiple Cassandra instances, habits on analytics, services, and everything else. It's fairly heavyweight. I believe we're somewhere between 20 and 50 containers for the entire Edge compute infrastructure. However, what the Tonstone Fabric project in 5.0 have done is create an ability to have a remote location which is treated as a pop that can operate with one or two containers or VMs as part of your infrastructure. This ties into a more central location where the advanced analytics and all of the rest of the control plane runs. So all you need to do to provide a couple of peering VMs at that central location and then you can fully utilize a converge control plane that can span across all of your Edge locations. Okay, so this is a little bit better picture that displays what's going on. So you have a couple of pops. The pops are running just V-Router. It was a gateway to get you out to the VLAN and then all you need is a couple of control elements that can bridge you to the rest of your contrail cluster and then you have a central UI, central analytics, central monitoring, central security policy administration and everything else at the cost of a very, very, very small footprint. Now, obviously, since Tonstone Fabric is an SDN provider, this doesn't quite finish the story because you have to select an open stack infrastructure on the Edge that will also have relatively minimal requirements. So maybe two server HA, if such as possible, or three servers at the most, but with ability to run meaningful workloads on the same servers as you have the control plane. So you still need to finish half of the story and you need to select the right open stack infrastructure that will deliver a minimal footprint while maximizing the usable compute capacity. So Intel had that technology, I believe now it's inherited by the Acreino project, so hopefully I'm hoping for them to succeed and get their stuff into some sort of production readiness shape in about a year. But I think both the canonical booth and the Red Hat booth are demonstrating some interesting Edge stuff and then Mirantis just released Kubernetes on the Edge, which is yet another spin on a potential Edge cloud. Okay, so let me give you a quick introduction to Tonstone Fabric for those of you who are not familiar what the project is all about. So Tonstone Fabric is a single SDN that bridges hybrid clouds, public clouds, private clouds. It also works across open stack Kubernetes and bare metal. So its control plane can be tied into the Neutron and CNI and can seamlessly bridge your Kubernetes to your VMware, to your open stack, to your bare metal environments. It could spin out to Kubernetes into the Amazon cloud and things like that. Right, so it's one SDN that wants to try to do to dominate the world and do everything on its own. It does succeed that. Some of the demos that you can see in some of the other Tonstone Fabric events, and does someone demonstrate those capabilities. Okay, so like I mentioned before, security is fairly important. This started in version four and advanced version five, and it's essentially an intent-based security management framework for Tonstone Fabric. So it's intent-based in a sense that you're going to define things on the basis of the applications. So that means that each application gets a security rule which will get interpreted correctly regardless of the context it runs in. Right, so it can run in dev mode, production mode, or any other mode. It'll still be a single rule that you have to define and maintain. You don't need to worry about the individual network endpoints. The framework will be capable of interpreting all of that. So this gives you ability to deploy essentially a distributed stateful L4 firewall across your entire network, including your public and private cloud. Oh, by the way, it can also do in the commercial version, not in the open-source version. It could do end-to-end encryption of your traffic if you so choose. And it actually does that in the commercial contrails version. When you go to the public cloud, it will encrypt your tunnel going from your data center into the public cloud. It assumes an untrusted infrastructure. So that provides you a very useful security stance. Now, with the service function changing, Tunnel Fabric can introduce ability to do more than L4. Right, you can do transparent IDS IPS, you can do L7. So I believe in the commercial version of the product Juniper has a CSRX that can serve as a very intelligent L7 firewall. Of course, fully distributed with the ECMP load balancing allowing you to scale up your CNIs. So this is how both the compact footprint and the additional security infrastructure that gives you uniform security policy management do provide basic service needs for the clouds. Obviously, you still need to find few other pieces, right? So you do need to select a distro which will give you a consistent edge deploy story. So ability to deploy and seamlessly upgrade, right? So this has been one of the biggest challenges in OpenStack. I think it's a problem that's partially solved and hopefully it'll be fully solved eventually. So you also need to still consider about how you're going to get your controller footprint on, let's say, a couple of cores from three servers and few gigabytes of RAM, right? So you still need to have a fairly compact OpenStack footprint in order to deliver edge. So there's various edge initiatives going on, right? So obviously OpenStack at the edge is one of them and this is an OpenStack summit, but if you're here as a user you should not ignore the several Kubernetes projects, including Kubernetes edge deployments that's going to be there. So at some point, both getting VMs and containers on your edge will be important and you should be paying attention to both. Okay, so this just gives you a picture of how the security policy can be transposed to multiple instances of the application running in the clouds. Obviously, you can also have an underlying policy that defines the difference between the security policy and production that's enforced underneath. That's not defined by the application owners. So that's it for my presentation and I'm open for questions. All right, thank you very much everybody. Have a wonderful day.