 So, welcome everyone. I'm very excited to be here. It was interesting, about a year and a half ago in San Francisco at the Design Summit, networking was discussed as a line, a straight line between two VMs. We suddenly come a very long way from there with substantial use cases and innovations in networking. And to talk about some of that, we would have the experts from both Rackspace and Brocade Viada here. So, I'm Sandeep Singh Kohli. I'm part of the product marketing team at Brocade. Sameer Satyam, do you want to please introduce yourself? Yeah, my name is Sameer Satyam. I'm the Product Manager for Public Cloud Networking at Rackspace. And I am responsible for onboarding or introducing network services for our public cloud customers. Hi, my name is Shashi Sastry. I'm the Technical Marketing Engineer for Viada. My role at Viada spans from product development, performance testing, and also to validate customer solutions, especially in the cloud service provider environment. Excellent. Thank you so much for taking the time. Glad to have you here. Really quickly, most of you know about Brocade's market leadership in San. A few of you might not know about our leadership in the IP world. So, just hit a couple of points really quickly. Brocade was the first to introduce Ethernet fabrics into the market. With our VCS plug-in, we provided the first fabric level orchestration. With the network function virtualization, our Brocade Viada V-Router has, with market penetration, it's leading in market penetration, if you consider the number of downloads it has had so far. So, a lot of exciting stuff happening at Brocade, both from the SAN perspective and data center IP perspective. At our booth, we are showcasing OpenStack integration with all of these solutions, FabriChannel SAN, Ethernet fabrics, Load Balancer, and Virtual Router. So, please stop by to get a little demo on all of these. So, Samir, why don't you give the audience a background about cloud networking and what Rackspace is doing in that respect? Sure. So, our network services portfolio is basically listed here. We started with what we call as cloud networks last year in September or October. Currently, we have basic layer 2 to layer 3 services, which includes private networking between virtual machines, what we call as isolated networks. We also have attaching network capabilities, broadcast and multicast capabilities on private networks, and we have the firewall and VPN router capabilities now with the Brocade Viada V-Router. We are still running NOVA network, actually, with a quantum or what used to be called quantum, and we are transitioning to Neutron early part of next year, and we are going to offer security groups functions as well as we are looking at floating IP and various layer 4 through layer 7 services as part of the public cloud. But this is what we have right now. So, you were talking about some of the technologies, but how are these offered, and when you're talking about these offerings, can you also touch upon the topic to your network function virtualization? Sure, yeah. I think you mentioned network functions virtualization. That's a standard term being used for most of the layer 4 through layer 7 services nowadays. So, there's several ways we can think of when it comes to offering layer 4 through layer 7 services. And when we say hybrid cloud, at track space, we have a dedicated or managed hosting offering as well as well as cloud. So, when customers consume these services, layer 4 through layer 7 services or all network services, either in the dedicated space, they'll have a dedicated firewall or a load balancer or any of those physical appliances. That's one way that they would like to consume these services. On the cloud side, there's a couple of ways to do it. They could be a service virtual machine, which is customers want to create a VM network appliance just like a server, they would want to spin up a network appliance virtual machine and be able to log into that virtual machine and make all the changes for the networking. The other way to consume the services as a service natively in OpenStack, we have VPN as a service, firewall as a service, all of those being pushed through the OpenStack community right now. And that's another way of consuming layer 4 through layer 7 services. Customers do not need to be logging into the network appliance, they just want to use API or the user interface in order to get these services. And the last way I think is basically, I mean, network functions virtualization, which is the term that's being used right now. It is also going in the path of distributed services, like which are offered on from, which can be done on the hypervisor itself or at various distributed points in the network. That's the difference. Absolutely. So why don't we back up a little and give a very high level view of what were the use cases that customers were coming up to you with and what was the business problem that you were trying to solve for them? So you just saw all the services that we offer. We have private network connectivity between virtual machines and for some, for let's say there's a web application deployment with various web servers, database servers. If we want to protect these web servers or if the database servers and the app servers need to connect to the internet but want to be secure and not expose their interfaces to the public, that's one of the use cases that we were trying to solve. The other one is, we have different regions in rack space. We just launched our Hong Kong data center this week, I think. Yeah, we are all wondering whether it's Monday, Tuesday or Saturday today. So customers would like to be able to, I guess, connect multiple data centers in rack space or even dedicated, I mean, different regions from customer data centers to the cloud. So that's the other thing that customers are looking for, either for disaster recovery purposes or just to span their applications. Disaster recovery is more of a common use case or just for connectivity between virtual machines across regions. The other one which is not mentioned here is routing between private networks. So let's say there's an app application which needs to be on multiple networks. Some servers are on network A, the other one is on network B and they want connectivity between those. That's another use case. And the last one is remote access or client VPN services. Basically the secure traffic between sites can also be routed and so that's the variant that you touched upon, right? Yeah, absolutely. Sashi, was this, were these use cases common with other service providers that you were talking to and did you have to look at it from a different angle for rack space? Tell us a little bit about how you went about. Sure, absolutely. Yeah, for Viara, this is for our current generation of product, this is a perfect use case as a tenant router in the cloud service provider environment where we can, it's a different model. We're spinning off Viara providing those layer three services per tenant. So let me just give you a brief introduction of what Viara is for people in the audience that don't know. It's essentially a software form factor. It's a router that provides routing, BGP OSPF, IPsec VPN, remote access VPN and NAT firewall capabilities. So it's essentially all these services in one software form factor. So with, we've seen what the use cases are, what the requirements are from a rack space perspective, right? They were trying to provide segregation, security for applications, for their customer applications. They needed this functionality per tenant, per customer and this could be generalized over other use cases per department within one large enterprise. So you can see that Viara here is acting as a gateway router. With NAT you hide the applications behind Viara and you expose the public interface of Viara to the internet and apply firewall policies to protect the applications behind or expose the applications as you wish to external traffic. That is one use case and that's generally the similar use case across other service providers that we work with. The second use case here in the picture that you see is trying to connect two sites. Here in the rack space use case there are two regions that we're trying to connect up two regions of the same customer maybe. They want to secure the traffic between those two sites but if you really think about it this can be extended to other larger use cases meaning you have connectivity between your branch office or your headquarters and your rack space environment or it could be between a rack space and AWS where we also provide the same kind of functionality. So this is a true hybrid cloud kind of connectivity here. The third one of course is kind of an extension. We are providing secure access to the applications using SSL VPN. So all of these can be with or without dynamic routing. But we can actually do dynamic routing and we can do that over the VPN tunnel. So it's very flexible to provide that connectivity at the same time securing the traffic. And this again is a common general use case and that's why we fit quite nicely to provide those functionality. So Sashi you were talking about how some of these use cases are pretty common with other service providers. So what is the value proposition? What is the differentiation of rack space where other service providers are having similar use cases and they're resolving that through routing and virtual solutions. What is that you do different and how is your offerings working for the customers? Yeah, so I talked about the various ways in which these services can be offered and here we're talking about offering layer 4 through layer 7 services on a virtual machine that's created. So customer needs to spin up a network appliance as a server. We recently launched performance flavors which is basically our next generation if you will of cloud flavor offerings. What this basically does is that Viata can be provisioned on these performance flavors and it gives us gives bandwidth flexibility for customers to choose from. So if they choose like a one gig performance class they can get 200 megabits per second bandwidth and they can go all the way to 1.6 gigabits per second with different flavor sizes that we offer in our cloud today. And all of these are as you can see the monthly basis there that starts from 160 dollars. But the real value as I said is that the bandwidth can scale up pretty quickly at very little cost and a lot of our customers who want high bandwidth capabilities and they can use they can pick and choose from these flavors and at not much cost relative to other cloud hosting providers. So performance flavors along with you know Viata's different use cases that's kind of what we saw here. Okay, excellent. So shifting gears and talking a little more about technology and the solution. I was discussing this with Yahoo Japan on Tuesday as well that OpenStack is soon becoming a collaboration platform where vendors and customers are changing their relationship from just you know transactional to true partnership. So this question is really for both of you how do you come together and coming up with the solution and maybe add some more details on the technology and the work that you know both the teams did. Sure, so from technical perspective basically we use Nova network right now and as I said we're transitioning to Neutron but from the the technical work requirements perspective we had a brocade Viata develop a Nova agent so that they can boot their system in our cloud. This Nova agent used file injection API from Nova which is I think right now being duplicated for config drive and cloud in it but since brocade was one of the earliest to do software defined networking virtual machines we went with doing a Nova agent with file injection capabilities and this is required because it need like if the VM needs to come up in our cloud they need to read the IP addressing information on all that is provided and come up with the right IP addressing information the right interfaces the right order of VMs so that's basically developing the agent with was the main portion of the integration work that happened and on our hypervisors. Sashi you wanted to add? Yeah sure it is indeed a different paradigm especially because it's no longer the requirements coming from the customer and the vendor trying to fulfill those requirements in in in a certain order and you know getting that out in a release out in a certain time frame it's more about a partnership as Sandeep mentioned so we had to have you can't just write a product requirements document and say okay this is what I need to build we had to have an engineer work very close in the rack space environment to do the actual development and this is not new for Viara we've done that a couple of times and we continue to do that because each environment is is unique each of these cloud service providers have a different deployment model their their hypervisors are made for that environment are built for that environment so we had to work very close in in lockstep order with them to fulfill these requirements just a little bit on what we had to do for Viara is that when Viara boots up now this is probably a little bit different from the application VMs we are the Viara router is it is a router so we need to have an IP IP address as as we come up or you know we boot completely also the few configuration parameters that we need before or during the bootstrap is actually turn on DHCP service on the interface have some SSH keys push some SSH keys so once the Viara boots up completely the administrator can go in and configure other services such as firewall VPN and so on and the third thing is to just have a default user so these are basic parameters that we need to push to Viara as it's booting up and that's what Sameer was referring to so we we just had to tweak that a bit in order for that to happen and that's specifically in in their environment so once Viara boots up then we can SSH to it or we can use REST API or any other a couple of other ways to to be able to push the actual layer three services configuration on to Viara. Excellent one thing that I forgot to add on when you ask for differentiation is I mean in other clouds when you offer the brocade or any other network appliances they're supported not supported by the cloud hosting provider but go to the vendors to support it in rack space this is actually part of our standard support of fanatical support right so yeah just add to add a plug for that exactly absolutely why don't I take this opportunity to open the flow for questions anyone in the audience have a question to us our panelists here so while you're thinking about some questions let me put a yes please do you want to repeat the question first for the yeah I'll repeat the question I think you're saying upgrading from no one network to brocade is a big change and why did we do this over corn trail and other solutions basically let me clarify one thing our networking is this is what we have right now is we are showing how we are offering a service to customers for routing VPN firewall these capabilities our network is still based on its public knowledge that we are networking is based on VMware's or NYSERA's controller so that's not changing this is this is just a service that we are offering as a VM inside that environment it's not so I mean can you also touch upon you know market places and how you so essentially this is networking service that's provided to the end tenant and so you want to add it's not like our networking is based on viata this is a VM in the network appliance offering inside our cloud so as eventually what we want to do is there's a lot more layer 4 through layer 7 services than just routing VPN and firewall so if you're familiar with aws marketplace there's a lot of network appliances that are part of that so rack space is looking at doing a marketplace in which there's not not only uh you know routing VPN firewall these kind of functions but there's several functions like web application firewall, TDoS prevention, van optimization there's so many other functions that need to be part of these layer 4 through layer 7 services so eventually we'll get there but you know this is just one of the offerings in all the list of offerings that I mentioned so routing VPN firewall, WAF, DDoS, van optimization and so I think maybe a misunderstanding what was your question about upgrading the open stack version and what it does to viata which maybe you should answer that's that's fine I think is that what was that your question because it's two independent things yeah it was just a matter of timing we've been we've been around forever go ahead and say what she's okay I gave him the answer yeah I think this is an I think your fundamental assumption is that we are our network is based on brocade which is not the right yeah what you're assuming is wrong yeah our network is the technology that we use in our network is SDN based off of VMware's NICERO offering I saw I saw another question from from here somewhere yeah I mean we obviously we are looking repeat the questions yeah if you could that would be helpful okay the question is are we are you looking at SR, IOV, DPDK and so on these other advanced technologies going forward in our public cloud so I'm not sure how many people are familiar with SR IOV and all that but I can quickly when you talk about a software defined networking currently the majority of the ways the providers how it's implemented when SDN with the help of a controller is you have open virtual switch on the hypervisor and the controller basically establishes a session with the hypervisor and OVS or the virtual switches where all the flows or the traffic forwarding decisions get pushed down from the controller there are other ways in which you know in order to increase the performance or improve the latency of the network you can architect the network in different ways so SR IOV is one such way in which you know the hypervisor OVS on the hypervisor is not actually doing the forwarding decisions but rather it's basically every tenant is handing off specific vlan and all the decisions might be made at the top of racks which and there we can do a vxlan handoff from there to the network so that's that's where I mean that's something that we are constantly evaluating we have a huge network and you know we have we have various cells in our network variously to domain so definitely we look at look at all of those technologies but we have a huge incumbent network with existing provide SDN provider that we have to keep in mind and Sashi did you also wanted to talk about what are some of the future enhancements with brokered viata v router and how sure what direction it's going at yeah so as I mentioned our current product is the viata subscription edition and it's a tenant the use case is mainly as a tenant router as a in a cloud service provider environment but what we are working on is a router the next generation product it's again called a virtual router there's a little bit of a lack of imagination there but it's purely for network functions virtualization and when I say network functions virtualization that can mean many things to again just like SDN many things to many people but for the viata in the viata sense it's purely for the service provider space where high performance high scale is key and so we'll be focusing on basing the VR on Intel dpdk architecture and some of the technology that we've talked about sri ov where we are bypassing the nick excuse me the virtual switch and connecting the viata interface directly to the physical nick but again some of the use cases here are pretty narrow it'll be purely routing routing with scale for example a bgp router reflector use case so this is essentially what we are working on any questions from this side of the room okay let's let's move back to the middle the gentleman in the back please can you speak a little louder so we do repeat the i can repeat how do you deal with the how do we deal with failures of the router i would like to say that viata has been around for quite a lot of time a lot of users about over a million downloads of the software so we are very very stable but we do support ha vrrp and we can have active standby configuration although again this is a unique environment service provider the cloud service provider environment depending on what they support for example in aws we it's a little bit more convoluted to run a vrrp so we have to do have to provide some other mechanisms based on that that environment and in rack space we can do vrrp i believe because they do support it depends on whether they support multicast for example for the keeper lives even though that's not a limitation we can do certain things like maybe do a gre tunnel but the just to briefly say that the environment defines how we provide the high availability so i mean did you want to add a little more color to it so viata does support brocade viata vrouter supports vrrp but from neutron we need this function called shared ip or virtual ip which can basically transfer between virtual machines we are going to get that to functionality early part of next year so once we get that and with the help of vrrp is just a data plane failover one we currently it's not supported in rack space club so we have a customer in a cloud service provider in japan ns solutions and they have a similar tenant use case and they use vrrp in their environment to provide high availability okay the gentleman in the white t-shirt please so the question is really the question is can do we plan to use vpn as a service and firewall as a service from from newton perspective right so yes we do plan to do that and our next way of services that we plan to offer includes floating ip security groups layer 4 through layer 7 services we need to run an l3 agent which is the l3 networking agent extension right so that's where we are figuring out the architecture currently where where to run that agent and what model we are going to use for those layers 4 through layer 7 services but yeah definitely our intent is to provide those services natively in using the open stack api yeah so so we um we we used to support it we repeat the question sorry does uh we are a support we are used to support cluster ha do we still support it uh we have moved away from that uh because it's a little bit more complicated and there were some issues with it so today we do active standby ha i know the audience has a lot of questions i want to get to one question real quick which is very intriguing you went through all these use cases right which particular use case is is most common and something that you really want to talk about a little more yeah the side to side vpn for connecting between regions or from a customer data center to rack space that's one of the most commonly deployed use case that we're seeing from customers for example there was a customer who has who's running a mongo db cluster and he's sharding from like his local data center um into rack space uh cloud across the side to side vpn uh and because it's also i guess secure that's a very good use case that i mean side to side vpn is the most common use case followed by i would say then is the second most common is the firewall use case that's uh which provides network based firewall services and can secure the web application okay excellent um please repeat the question i i think that's so we can repeat the question is how do we guarantee the throughput i mean the word guarantee when you use it in cloud that's like a very dangerous term i don't think any customer actually guarantees like but we have certain slas that we try to meet and uh when you guarantee the relative term slas if you go back to the uh how do we guarantee it yeah we have built capacity in our clouds with the right amount of um oversubscription built in and we've modeled and we have a here i mean our design of top of rack aggregation core it considers how many vms are part of the uh can be on each hypervisor and then we build uh bottoms up based on that and also historically we have a view of how many um customers are sending what amount of bandwidth so using bottoms up approach as well as you know data from what we have learned um we do uh guarantee well not guarantee but we we offer this is uh uh like different flavors can do different amounts of bandwidth right slas right so um sashi um some other conversations that you're having with um you know rack space and others um service variety customers what are the sla discussions uh you're seeing yeah so uh the the whole performance throughput conversation is a little bit different uh especially in the virtual environment uh we um if if it was a proprietary appliance um i come from that word if it world if it's a hardware appliance we know exactly what we've built uh we can characterize that very easily and provide all these uh nice numbers on a data sheet but when we go into this virtual uh environment and especially a cloud service environment it's a much more difficult task um because uh we are running on uh an x86 server uh which may or may not have hypervisors uh there are driver dependencies um so i mean we can do what we do inside viara is we characterize on certain platforms on a server on certain nicks uh with certain drivers uh tuned to the highest performance uh and then we give that as a baseline in the lab in under ideal conditions um and then we guide customers uh as to you know what the throughput and um maybe in their environment on their servers you know and and so on so there's there's uh there's actually a lot that has to happen in that conversation right um any any other questions that that come to your mind um any any final thoughts sashi and samir that you wanted to share go rack space fanatical support so i would uh encourage you to be available uh on marketplace in aws and of course uh in rack space so please go give us a try and don't go to aws i knew i would get in trouble exactly exactly uh thank you so much samir for you know taking this time and and sharing uh uh your thoughts and and likewise uh sashi for doing that thanks thanks for being here first