 Good afternoon. Thanks for joining us. Initially I thought I'll be talking to ten people and five of them are gonna be wearing blue shirts so it's good to see that we got more and more in the audience. So my name is Oded. I work for Plumgrid as a system engineer and I've got about 20 minutes to give you about an hour worth of content so we're gonna kind of rush through some of the slides. We are going to do a demo so this is a live demo. I know this is a demo theory and we promise you that so let's cover that but before we get to the demo just a couple of slides about what it is that we do. So at Plumgrid we developed virtualized network infrastructure to power up you know the next generation the modern data center and when we started looking at some of these capabilities of what SDN is some of the things that we wanted to achieve is to be able for example to create a software stack that can run on any network and can be scalable and can provide security and can be used things like a policy-driven type of an attribute. Okay so this is a what we kind of set our sights to build. We are a software only solution running as an overlay in the SDN kind of a space. So for those of us who've been in the cloud space for quite some time we all understand that networking in the cloud has been kind of a lagging behind some of the advancements and innovation that we saw coming from the compute and the storage world and we're we had to play a little bit of catch up to kind of close this gap of what networking needs to be done and to allow this next generation data center that really comes down to how do we automate things in the data center. Okay how I can give an application or some kind of a higher layer obstruction the ability to go into orchestrate things not only from a compute perspective and from a storage perspective but also from the network and the way for us to do that is really look at software defined networks. We all realize that the physical network is a bit of a challenge and if I got to orchestrate something in the physical world it's pretty much sending somebody to the data center to move cables around and that just didn't work for us anymore. So that was what we were trying to solve when we started Plumgate about three years ago. So we're in an OpenStack conference and I'm sure some of you guys are asking so hold on we already have a solution for networking in OpenStack right and we call this neutron. Why do we need other solutions right what's wrong with with neutron so let me start by saying that first of all nothing is wrong with neutron okay and neutron the way that we kind of see it neutron is this overall umbrella of network services that can live within the OpenStack kind of a framework and when we look at neutron from an API perspective this is kind of the unified language that we have. We got a set of APIs and if I want to build something from a network I call the API. Hey go and create a network create a subnet create a router connect those together so a user or an application can go then connect and consume these services. The challenge for us began when you look what's underneath neutron and some of these components that happens kind of underneath the API layer and this is where we started seeing some of the challenges about things like the network node things like agents things like OVS and if you just look at the typical deployment of a neutron using the OVS and some of the agents that presented a challenge for a lot of companies and you know our booth is right over there and I think half of the people that woke up and talked to us are saying the same thing it says we're trying to build this network we've got a challenge with neutron it doesn't scale we need HA we need something that looks a little bit better so given that as the context of what we were trying to solve keep that picture in mind I'm going to go back to a similar picture in a little while that shows you how this looks with with plum grid components underneath before we get to look at how we do that I want to take a step backward and talk about virtual domains and I think this is maybe one of the most unique things about the technology that we've built that really helps understand why this is so unique okay and when we talk about network virtualization some of the things that we want to understand is really the operational elements of how do we operate a virtual network or an SDN so we started thinking about this say okay we've got API's and we've got programmable data planes and we got software switches but we kind of looked at how virtual machines are being created in the network and some of the advance that virtual machine gives the IT world and how it really revolutionized the way we do things and we saw some similarities between these two approaches look at a virtual machine it's a software container okay it's completely decoupled from the hardware that it runs on it has an identity I can assign it to a user I can copy it I can move it I can clone it and I can put an application and an operating system in it right we wanted to take the same thing but build it for a network okay can we take this software container this blank canvas okay instead of an operating system and application we would put a network function okay and this is where we came up with a concept of a virtual domain and if you look at it this solves a lot of the operational problems that if you're an application developer and you want to just call some kind of an API or do some kind of an automation so this is the perfect model for you this is something that you can understand okay scalability that's another thing that we were able to achieve using this domain the footprint of a virtual domain is is very very small on your infrastructure so we're looking at thousands of virtual domains okay think of a virtual domain as a tenant or an application or any other isolation container that you want in your cloud obviously multi-tenancy is a given some of the things that we can do also in the virtual domain is actually encrypt those if you're running a bank this is extremely important for you traffic from your virtual domain might passes through multiple servers you want to encrypt that data in between fault isolation sometimes an overlooked feature of what we do but I know the networking guys they are gonna love it if you mess up this virtual network you only messed up the virtual domain your physical network is gonna stay intact and this is something very very important we could also do things like visibility and scalability and everything that you can get from a software type of a solution that runs in your data center so why do we believe this is the right architecture for the cloud and again I think there's a certain disconnect between how server guys or application guys see a cloud to how networking guys see a cloud okay and anybody here that's trying to build clouds will know that there's a certain kind of disconnect between these two people what this virtual domain notion gives us is a language that some of these guys can actually understand if I'm an application developer what I have in mind is the top picture it's the automation it's the API it's software defined I don't need to understand how a physical network is built if I'm a network guy or a data center architect the bottom part of this is what I understand so in a way we kind of give people the ability to do both things design your data center in the proper way using all of the best practice of how data centers should be designed but still give the agility of a cloud into your developers into your server guys into the people that I want to leverage those resources coming from your data center and if we look at kind of an example of how this is then being projected into your network think for example a tenant number two that's his virtual domain that's a virtual topology right and once this is actually being rendered or pushed into the topology it becomes the virtual network that lives and runs in the data plane of the solution okay some of the components that we have in our solution again there's there's there's a lot of innovation that went into this technology I mean we started working we actually started by developing the data plane component you know in SDN we always have the data plane this is where packets are running control plane with this is where the logic is we started building the data plane component that we called the iOvisor or the iOvisor edge this is a programmable data plane component that lives inside a Linux kernel okay it replaces kind of the OVS okay so if you guys know of OVS we sit right next to it so we take it out that we put that one of the unique things about this component that it's a fully distributed programmable data plane that means that you can write new functions into it in a very easy and automated way so once we solve that we have to put some control plane in place and the control plane again to solve some of the resiliency problems that we saw with neutron we developed a highly available director clusters the reason we call these guys directors and not controllers because in many situations they don't actually control the traffic they orchestrate virtual domains into the data plane so once a virtual domain is actually being rendered into the topology we support the headless operation that means I can take out the directors everything that's being pushed in the topology into the data plane will continue to work without any problems so going back to this picture that we had earlier on here is open stack here is neutron we do support all of the neutron API's okay so but anything underneath the API going down is all plumb grid we take out the OBS we take out ML to we take out open flow everything is then being changed so the reason we maintain the neutron API is the because this gives us this compatibility with everything else that rides on top of open star so to make kind of the analogy you know you get to drive the car in the exact same way but the engine is completely different now okay so for you as a user it becomes transparent okay you get the capabilities of the Iovizer the performance scalability resiliency the API's stay the same once the API is pushed into our director cluster these virtual domains or virtual topologies are being created and then they're being pushed into the data plane component and you kind of see the illustrated version of it okay right on time I promised you guys a demo because we are a little bit adventurous we're gonna do a live demo and we've been praying all morning for the demo gods so hopefully everything is gonna work so what we've got here is an open stack deployment this is a red hat flavor we do support all of the other distributions by the way we're standard neutron plug-in but this one is running on on red hat and what I've got here just to quickly switch into the to the project side on the network I've kind of created some of these components in advance to save us some time this is a standard type of a network I got the external connectivity of a router I have another network which is kind of the tenant network and I've got a VM connected to it so everything that was done here from the Neutron API from Horizon I didn't mess with anything else let's see how this thing looks like in the plum grid user interface so as I go and create these components in open stack these kind of icons suddenly appear into my canvas okay remember the canvas that you get to draw your topology so this is now my topology now the cool thing about these things is that these are all live component of a network okay I can click on the router and get some information about it I can look at a static route list okay and this can be populated you can add entries to that I can look at my not for example is there any outbound or any configurations that I've got writing on my not by the way everything you see on the topology here is fully distributed into the data plane nothing runs as a VM nothing run in a control plane okay so I also have a virtual machine that is running to see the virtual machine we actually can see it here with its UUID but let's look at it from from Horizon so just a small virtual machine we call it seros what I want to show you today is a new feature we just released in this version which is open stack networking suite version 2 and it's an internal DNS feature so some of you know this is a project that actually happening in neutron that's called designate it's not released yet we've kind of a little bit ahead of the curve we do support all of these APIs that coming from but we're able to implement that DNS as a again a distributed function into our data plane which allows you to basically do name resolution inside your virtual network inside your virtual domain so to show you that let's first of all see if this VM is up okay we don't have the external connectivity here because of the network but let's go and create another VM and see if we can get the name resolution to work at least internally so this is going to be an Ubuntu VM let's call it Ubuntu 7 yep we also need to tie it to a network by the way once this VM is booting up let's look at the seros VM and how it shows up in our DNS so if I'm looking at my DNS component here and eventually it will come up no okay one of those right-click options actually does give me to see the host when it was registered to the DNS when the host comes up it goes there registers itself in the DNS so I can see the host name here I can just see some of the static routes if I've decided to use any static routes anything that has to do with the zone attributes okay so this is my domain so this is a fully functional internal DNS to my environment now obviously in a multi-tenancy environment you'll be running namespaces so you have the same kind of an IP addressing across multiple cloud or multiple tenants each with the same IP address scheme different domain and your name resolution is going to stay contained to your virtual domain so so we got 40 seconds for questions and if not like I said we're both e18 right over there please come talk to us if you want to and thank you very much