 Good morning everybody. My name is Marc Campoport. I'm a senior product manager in Geneva and I'm delighted to be here with you for the first edition of this OpenStack day here in beautiful Prague. Just a bit about me. In terms of the control product management team, I've been focusing mostly on telco and service provider use cases like NFV, that leverage OpenStack at their virtual infrastructure layer. This is a market that control originally targeted when it started like 2-3 years ago and we've already had a great success in this market with telco for NFV use cases like AT&T and Verizon in the US or DT and Orange here in Europe, AT&T in Asia. Now I understand that your topic and focus is more on the enterprise use cases and like cloud service provider use case so that's what I'm going to focus on this morning. Okay, I'm not going to be as brave as Jacob and Lachlan doing a live demo in front of a big audience. What they have presented this morning was covering both OpenStack deployment with Kubernetes and OpenControl and I'm just going to give you an insight on a number of customer use cases, some of our customers who are using OpenControl for their deployments, including the ones from Lithium and TCP Cloud. Okay, briefly what are the trends we have seen in the cloud market area? The hardware layer, the converge, hyperconverge trend is very hard. It's about simplifying and solidizing the whole hardware infrastructure for cost optimization, simplification and scaling and at the same time we see a number of functions and intelligence and use to be managed directly at the hardware layer that I'm moving in the upper software layer like TCP to be the cloud orchestration layer with OpenStack. At the same time, it's all about open source and we see a great adoption of open source at every layer in the stack, not just at the OpenStack layer obviously but also originally at the hardware layer which we've seen in the hyperconverge with projects like OpenCube project for example that you can do by Facebook but also things like CoS, KDM, Kubernetes and so on. So every element in the stack is moving towards open source. On the application development front we've seen that all the rage is around microservices moving away from vertically integrated monolithic applications for the reasons that were presented, all the benefits it gives you in terms of fast development and even faster deployment and portability which is critical in this environment. And lastly we see this huge trend towards private and hybrid clouds. Most enterprises are transitioning to SaaS for their regular enterprise services that provides better pricing, better feature. They are pretty much refocusing on their core business and critical application for their private development application. Now I want just to focus quickly on this public and SaaS cloud adoption trend to see what's happening. We've seen first of all the classical enterprise applications like main ERP so on and so forth moving from on-site deployment to pure SaaS model. At the same time the developers that are moving from the monolithic internal development framework, when they move to a past type of framework they have the possibility to use it either for internal private cloud or to use a public cloud and they need interconnectivity between the two or not all the content of all applications resides in one or the other. There are a number of enterprise critical data that still resides inside the enterprise network. Now quickly I'm not going to make a broad pitch on Contrail. I'm going to give you a quick overview of what Contrail is and what it can do. We have a more detailed deep dive session this afternoon that's going to be covered by my colleague at 2 p.m. I believe. So what is Contrail? In a nutshell, it is the Juniper open source initiative based on Apache V2 licenses to provide network virtualization in the cloud environment. Obviously OpenStack targeted but not limited to OpenStack. It also supports container environment and bare metal workloads. It's fully API driven, supporting all types of automations. OpenStack neutral is obviously implemented but also Amazon EC2 APIs are also supported. And it's kind of great in terms of being able to horizontally scale to provide pretty much unlimited deployment in terms of either single data center or multi-data center coverage. It's a high performance morning and I will go into more detail to help that dedicated implementation for the floating plane that resides in every codecube nodes. So since we are in an OpenStack event, I think it makes sense to refer to some of the latest survey that was published after the OpenStack summit in Austin two months ago. And obviously we see that the regular OpenV switch neutral implementation are the most common deployments used by OpenStack users. And this is fine for, I would say, regular deployments. Having said that for demanding users who have complex use cases, large scale deployments that need advanced features like service changing, for example, OpenControl is leading the pack in terms of SDN control implementation. A quick overview of the different features that OpenControl provides and hardware in the afternoon is going to go into a couple of more detailed capabilities, especially around security and service changing. I just want to highlight a couple of them, which are really different shaders compared to what Vali-Lan Neutron can provide or even some of the other SDN control on the market. Security, which is really a key component on how you provide multi-tenancy and isolation across your different tenants. And this is something that is managed not only at the individual virtual machine layer, but across each and every virtual network where we have a rich policy engine to define what are the networking connectivity and security rules across different tenants and workloads. A rich analytic engine, which is another major differentiator that I will cover at the end of the presentation, some of the benefits of the analytics engine that we have, like for example, being able to do underlay, overlay correlation, giving you real-time or historical statistics of what's happening inside your network. And service changing, which is one of the key requirements for a number of NFV use cases where you need to be able to steer the traffic between two tenants through a specific network functions like a security engine, a firewall, or any type of order you have. So what is our approach to open source? Open control is, first of all, we have two main tools that we use to manage the product. All the source code is hosted in a repo in GitHub. And at the same time, we use Launchpad for the management of the product, like the features, requirements, blueprint, but all of this is visible in Launchpad. And we get requests either from customers or open source users that are started through Launchpad. The community is developing the product. It's mainly driven by our engineers in Geneva, but there are also a number of external contributors. And then from there, we provide regular releases, typically three major releases per year with a number of minor backfixes, the release is coming also along the way. And the main differences between the user of the open control product versus the commercial license version that Juniper provides is basically the packaging and the hardening that we are doing around it and the capacity to get like 247 online support. So we have a number of packaging actually for the control product. The first one, which is the one that is used by enterprise customers in the cloud networking, this is really our SDN product that provides a network organization layer that supports pretty much most of the main open stack orchestration vendors, Red Hat, Mirantis, Canonico. Now for customers who want a more software package approach, we have the control cloud product which provides on top of the networking pieces, the server management component, SEPH for scale out storage, embedded integrated open stack implementation based on Canonico and Ubuntu for the host OS. And lastly, we also have like a cloud interact approach, our control cloud reference architecture, which provides a really fully tested and integrated solution that includes the entire hardware interact, obviously the compute servers, but also the storage switches and the routers. This is part of our ecosystem where we have a number of partners while being tested and integrated in our solution. First of all, the NFB vendors here that provides solutions like firewall, we support our own SRX and virtual SRX firewall obviously. We're also load balancing products, cloud caching, TPI, SBC and other security vendors are also integrated into solution. As I mentioned earlier, we support all the major open stack distributions obviously, but also Docker and Kubernetes integrations that are being used for example that were demonstrated this morning. And we also have an initiative to actually provide even faster performance by integrating our 40 plane component, the V-Router engine inside the NIC of the servers and we are working with major NIC vendors like Intel, Broadcore or Netronome to implement this component directly inside the NIC to provide hardware acceleration. So let's talk about the customer use cases. Before I'm going to cover the five, six main enterprise use cases, just wanted to give you one summarized view. Basically, WebContrain provides all these different customers. It's the networking clue for the entire cloud and enterprise network, starting from the legacy servers and storage based on VLAN configuration using VMware virtualization environment. Obviously, all the open stack, KVM, Docker and Kubernetes environment is supported and we allow you to service chain the traffic between different workloads through network functions whether they are physical network functions, appliances provided by F5, 8 and all these guys but also virtual network functions. And we provide connectivity inside the data center and also outside either to public cloud vendors like Google, Amazon so on and so forth and to the enterprise network typically when you want to provide connectivity all the way to enterprise branch. This is a bug that we also cover in terms of connectivity and you can apply the entire set of services across these different endpoints. So let's talk about the first enterprise use case that we have implemented. This is something we've done with eBay Classify but also of other customers, a large cable operator in US and also one of the largest smartphone vendor based in California. I guess you can guess what to hear about. So what are the needs of these customers? Basically what they want to do is provide an IT as a service capability for their internal users, developers and application users on both sides. It's about providing multi-tenancy so isolation across the different businesses or departments on demand resource allocation all provided through either user interface and also APIs. Having a rich set of security policy configuration and enforcement being able to really implement all the security policies directly on the endpoints in the servers for scalability and performance and leveraging the RBAC framework that is already used typically for OpenStack with Keystone. That's pretty much our here, maybe one element worth mentioning here. The entire connectivity is now using our product which is software based at the same time in order to provide connectivity outside of this data center. We use our MX routers which are used as data center gateway to provide connectivity either to public internet or to other data centers. Another similar use case that was implemented by Simon Tech is around big data. So configuration here is very similar with the difference that all the HANU clusters obviously run on their metal and that's how they are integrated. This use case also leverage our virtual firewall VSRX to provide security across the different tans and networks and as in the previous use case all the services sell provision and leveraging our set of APIs for the deployment of the different network policies. Now if we talk a bit about public and hybrid cloud this is a use case that was built by CloudWatch. CloudWatch is a French based operator that provides public cloud services. It was acquired by Orange a couple of years ago and it's one of the contributors to OpenControl. So what they wanted to deliver was a secure multi-tenancy infrastructure to allow their own customers to onboard the application and also have an as-a-service model for the different networking and security functions like you can as a service don't balancer as a service firewall as a service all of this using policy creation that are defined directly by the end users and one of the key differentiators that we are providing in this solution is the analytics capabilities which give visibility not only to CloudWatch but also to their users in terms of what's happening on the network having monitoring tools OK, how much time left? Another use case that we have with Workday which is one of the top five SaaS providers in US is providing SaaS Cloud. So here it was about giving multi-tenancy capability for high-scanned SaaS workloads for their enterprise services. I don't know if there is any Workday user in anyone. So it's really replacing the typical HR office and enterprise ERP types of services provided in a SaaS type of environment. And here what we've done is integration with private and VPC services all this is done using the service portal that allow all the customers to register. The internal developers can request services in the different Clouds that are distributed across the whole Workday network using different availability zones. Some of the apps are running in OpenStack and other apps which are not virtualized are currently running in Docker. In the interest of time, I will probably skip this use case and I'll just give you a brief coverage of the Internet of Things use case which is actually the one that DCT allowed them up. So here it's one of the key components as mentioned earlier is the fact that we have small OpenStack distributed implementations across the entire area with inside each Raspberry Pi V-warded engine that provide the networking connectivity between a local, I think, design light of a smart city that can be pretty much any smart device that needs to be connected to the Internet. And so Contran is providing the network orchestration across these different distributed compute nodes that run inside the Raspberry Pi and the centralized data center that run the application. So just to summarize the key different areas of the Contran solution compared to, let's say, regular neutral capabilities that you could get with a vanilla OpenStack, the performance that the V-warder provides. It's capable of running layer 2 and layer 3 running but also VPN layer 3 weekend connectivity and layer 4 plus firewall capabilities without the need to deploy or steer the traffic to actual virtual firewall. Obviously, you need to go all the way to layer 7 firewall that's where you need to run and deploy your virtual network firewall. Under scaling, we have a fully distributed control plane where you can basically horizontally scale it by deploying more instances, all the instances of the control plane synchronize their states using BGP. And on top of it, you can also have a hierarchy of controllers with a master controller that is managing a number of distributed controllers that will be deployed across multiple data centers. Every component is duplicated for a high probability. We are using Open Source components, standard protocols like BGP or VSTP to provide maximum integrity with the other components and vendors in the solution, whether it's any type of hardware vendor for the servers, for the routers, for the switches but also the different OSS and DSS vendors. And last but not least, the analytics engines that give you real-time flow reporting and also historical visibility, log analysis and coordination between the underlay and the overlay network. And that's pretty much it. Questions?