 Okay, hello everyone. It's good to be here at OpenStack Barcelona My name is Aaron Sarkanik. I'm a software engineer at brocade. I've been there for about two years On my right. This is Komuro-san from entity West. He's been an engineer there for 20 years And he was the one who introduced OpenStack into entity West's Production Network and on my left also from brocade is Nakano-san who has been in the telecommunications industry for over 20 years So this presentation is about How entity West introduced OpenStack into their production environment and how they are going to expand on that When they will and what they they plan to do So they're planning to take control of their physical multi-vendor network using open daylight and Exposing as a service through OpenStack So without further ado, I'd like to take it over to Komuro-san who will begin the presentation Mm-hmm. Yes. Thank you. This is just a disclaimer. There's a proof of concept. Yeah Okay, hi, I'm Shigeaki Kimura from entity West In order to try out the linkage function of OpenStack and open daylight We tried out we tried to build an experimental environment as POC The purpose of this POC is as follows To set up the physical network devices. We utilize the southbound interface of open daylight present this capability northbound as an OpenStack service with OpenStack API and Horizon dashboard. I explained the background of Trying out We entity West made a private IS environment using OpenStack But only the pure OpenStack functionality It did not fulfill the our functional requirement for IPv6 So we did not use the load balancer and the firewall functionality Provided by the Newton in the OpenStack environment Instead we use the physical network devices Now we can fulfill functional requirement, but in exchange for this result The tenant user has become impossible to use the self service functionality Our point of view this is a comparison of the VNF and the physical network devices this and at first about the VNF This assumes a virtual network functions provided by the OpenStack Newton There are various advantages to the VNF on On the other hand, it's not yet satisfied for us as Mentioned because we are restricted in functionality and We also distract about performance On the other hand It's about the physical network devices We can be fully satisfied with their functionality and performance because They are equipments that we have used up to now However, in order to take advantage them in the IS environment using the OpenStack We need to consider the following point At first, although the physical network devices already have some of the API But it's hard to use because it's not optimized for use from the OpenStack In addition, their equipments have excessive functions in order to provide as a service They are too difficult for OpenStack tenant user, especially application developers They should have been a little more abstract and The user should be able to use them in the minimal configuration The result of this POC we conformed the following At first young model configuration standard of physical fire appliance Second, Open Daylight application is able to manage the device programmatically in a network-like manner using CLI and SSH Third, once tenancy was inherited to the device Fourth, the device capability was exposed as an OpenStack service Finally, device configuration management possible through Horizon UI As a result, the challenges that I mentioned before is almost resolved by this POC And this can provide its functionality that we expected to use as In other words, as if application developers are, if they are using the firewall as a service of Newton They can easily use two complex firewall devices Thank you, Kimura-san Okay, so I kind of stole the triple low acronym here and made it my own And just before I begin, I'd just like to start by thanking my colleague John Castro Who unfortunately couldn't be here. He was really looking forward to it But he developed much of the solution that we're going to go through today So getting started So traditional Neutron, a traditional OpenStack deployment with Neutron is simple And it works well if all you need to do is some basic DC switching Maybe with VLAN or VXLAN It provides extensibility through the ML2 mechanism drivers But it does have some caveats around scalability So integrating ODL with OpenStack is a bit of an effort But you do gain the benefits of HA and scalability And you no longer need these OBS agents running on the compute nodes Multiple OpenDali projects are used as the implementation And this is the benefit as they have their own interfaces Which can be leveraged if you're going to create your own networking solution But in this POC, we took ODL further And we leveraged not only the many southbound interfaces But also the architecture to control physical underlay network equipment And expose this capability through OpenStack So moving on and looking some of the advantages of using OpenDalight Or programming for OpenDalight is that it gives you topology discovery Which gives you a centralized view of the devices and their runtime configuration So it's easier to perform management and troubleshooting Scalability, so you no longer have to have those 1,000 OBS agents running on those 1,000 nodes If that's how big your compute node cluster is Now you just need one logically clustered controller The multiple southbound APIs mean that you can provide support for almost any device Through Netcom for OpenFlow or VizDB But in our case, as it was a legacy device, we actually modeled the CLI configuration And we created a southbound interface for that and a northbound one And the modular, the MD cell architecture, which makes up OpenDalight Means that you can swap out one implementation for another Use one project with another and form your perfect network solution So looking at the PSC, what we did in the PSC from a high level So what entity West wanted was the ability for a tenant to come in And have a firewall either assigned to them or they can assign one to them So they would have a network full of these physical firewalls And they could assign one to a particular project in OpenStack And a tenant could go in and configure it using the Horizon UI So for example, configuring access lists as we'll see later Then this would, when submitting the form in Horizon This would translate to REST calls to the OpenStack service that we created And which in turn would decompose this action into OpenDalight REST conf calls To this CLI plugin that we created So, and these calls would then be further translated down to SSH And it would reliably push that configuration, those configuration Stands us to the device with rollback mechanisms and so on So this allowed, this gives developers the tools To easily, the familiar with like REST APIs And we use the templating language which we'll go in when we dive in Of course ideally we would have liked if these physical devices supported something like NetCon For OBSDB or something similar But by creating this abstraction layer, we were able to utilize this programmatic approach To these legacy devices So now diving into the solution, so it's kind of broken up into these two bits So we had the bespoke OpenStack service And also the OpenDalight project that we created So within OpenStack, there's a big developer toolchain such as CookieCutter Which you can usually quickly create a new OpenStack service And also use Horizon and the built-in tools there to create the UI And you can leverage things like Keystone so that you can know which tenant is logged in and so forth And build restrictions around that So it was like a typical OpenStack service where you have the API Which says most of the heavy lifting and also the Python client And we also created this modular kind of structure So that each device as you can see there by A, B and C Would make its own particular REST conf calls to OpenDalight To the CLI REST interface Which would be translated down into the CLI and SSH connection at the end We modeled, in OpenDalight we modeled the device's configuration using Yang Which allowed it and YangTools is one of the tools in OpenDalight Which passes these Yang models and you generate a REST conf interface And it's self-documenting as you'll see by the Swagger UI when we demo this next And we also used velocity templating and a custom, we created a custom DSL Which would translate these REST calls into those configuration standards And then the CLI engine of course pushed them reliably down So what this actually gave NTTS is not non-proficient operators in a device They don't need domain knowledge or the device to configure it and use it So going through the demo, so just jump across So here we can see that the dashboard that we created So the device that we modeled in this case was the Cisco ASA With the BSC dashboard here and we're going to be adding an ASA firewall So this is a connection of one so we're just logging in Just showing you that this is what we're going to mount in a NetConf-like manner But using this CLI abstraction layer So I'm just grabbing the interface now, the IP address So what it will do is SSH into it and mount it into Open Dayline So just giving it a name Cinefirewall with the IP address, the username password as you would If there was an enabled password you'd put that in the port that SSH is listening on And assign it to a project So doing this mounts the device on Open Dayline And now a user is able to go in there And configure different configuration standards within So for example, the first thing they can configure is say the interface So here we go back and we can see that this interface you could be in Ethernet 2 doesn't have any config It's just got the standard config So going in and using the UI we can go and edit that interface Add a name for it, add an IP address Add a net mask And a security level And then this will be pushed reliably down to the device using that abstracted layer So we can see that it's being pushed down So we've got a name, that security level So most of the CRUD operations were supported so we could edit that interface And maybe we wanted to change that security level So as you can see it's very easy now to configure a physical device There's no need for an engineer to go and log in to the device And have to memorize all these commands They can just use the UI So here we're going to show an access list So there's no access list currently on this firewall And so we can go configure them So giving them a name Also the ability to order them So in this case we're going to permit the Google DNS through Saying TCP You know, it kind of matches the CLI structure of the device The UI and the API It's actually quite easy for these operators So they go and submit that And you can see that the access list is there They can delete it And if we go back and switch back to the device You can now see that that's being pushed down So we do very much the same thing again So we add another device Deny all So just an explicit deny at the end Add a remark and we can see that that's successfully being pushed down again So a name that's easy to remember as well And a remark for any other engineer that goes through You can also use the API of Open Daylight To query Open Daylight And get the status of the device The configuration You can see that it's all in JSON So you can integrate this further into any other system That you may have So in this example we've just done Giving all the access lists And you can also do other operations Like push device configuration So here we just add another one We change it so that the destination host is that And we push that through And then you get the standard HTTP response code So we've got a 200 ok So it's being pushed through And we can go see that by querying the device Open Daylight again And we can see yes that's in there And if we go in to the terminal We can see on that device That it in fact has been pushed through And as you can see We had modelled quite a bit of this device So we were able to add access groups as well So one access group for every device Deny all, set that access group And we can see that that's being pushed through And even This is the REST API documentation Generated by Open Daylight So you get all this for free It uses the swagger UI So any of your developers can come in And know how the API works You can see that They can see what they need to push through What they're going to get back And so on In this case we're saying Give us the banners for this device And let's go configure one So we configure the message of the day And we're going to say Hello Barcelona And we push that through And you can see that In the REST documentation Page again That's come through And also if we go through the device We can see that that's pushed through to the device That concludes the demo Switching back to the presentation So with Neutron and Open Daylight So they're complementary So Neutron, they can coexist So Neutron is great at doing the layer 2 DC switching But if you really want to reach into The underlay And program the physical devices Using a multitude of different Southbound APIs You can now do that With the use of Open Daylight And now I'm going to go back to Kimura-san Who's going to conclude the presentation And talk about some of the futures Okay Thank you Dari Next We'll talk about the future Outlook and activities About the OpenStack And the NFV In our point of view In the IR environment Using OpenStack We think that There is still a gap Between the ideal world And the reality one Especially About the expectation For the network function The ideal server platform That we want to get Is SDI All of the network function Is the virtual presence Of the software In other words It's the NFV The underlayer Of the infrastructure In the ideal SDI environment Is composed of Commodity server equipment And simple function hardware Switches It's the environment That the SDN controller Manages all of the control And Can be used Without considering differences In the individual device series However The environment In which we currently available Is not reached yet Actually up there Still in short time We need to continue To take advantage Of dedicated equipment In the OpenStack Underlayer environment NTT West would like to make SDI capable overlay network first The NTT West will make SDI-based private server firm Using OpenStack There are two points In this challenge How to involve hardware equipment Into SDI environment seamlessly And using multibender equipment In this slide It's described that We want to achieve In our infrastructure OpenStack tenants Will be able to operate The following physical network functions At their two switch VLAN creation VLAN creation And port assignment At router Virtual router creation And VLAN assignment Routing configuration At file Context, virtual file creation And VLAN assignment And file policy configuration It is We got it in this POC And load balancer is same Same as file That is to say It can be naturally realized In the virtual network of Neutron We want also to realize seamlessly The same things as the Neutron In the world of one underlay Made up of physical network devices At last The NTT West continues to utilize OpenStack And is an active member of the committee By utilizing open daylight It's possible to extend the functionality of OpenStack And NTT West continues to explore Other technologies as well That's all. Thank you Thank you Thank you Any questions? Be gentle It's my first time To extend The configuration standards That you can present up as an OpenStack service As I showed the API That can be integrated into any system You can write your own application That uses that API To configure that As long as there's access to that open daylight controller Which is where that REST API lives Any other questions? In a logical cluster So there is Because it's an ACCA It uses the ACCA framework So there's some state distribution Of the configuration data store Where when you push a REST request That's kind of sharded Onto the other data stores So if one goes down They have that quorum That takes over So another one becomes a master Definitely not as a future But it's a stopgap For legacy devices Because a lot of physical networking equipment Doesn't support netconf And if it does It doesn't work that well So it's a way to Be able to programmatically access These legacy devices That an operator might have As a result of that So the CLI engine That was created Actually you can do commands To check if that was applied properly So we do go and check If that configuration was applied properly What should And then we return that response code What were we using So that was a custom interface Developed for this proof of concept So it's like a CLI southbound interface So using the same kind of Yang modeling And MD cell architecture That you would develop Any other open daylight application So we developed one of those A southbound plugin basically And it was it So we modeled the device And we also write this velocity template And we created some custom directives To make it like our own DSL And yes in the end We are kind of using regex To pass that And kind of create that So it is a bit convoluted But it does work It gets the job done Anyone else? Okay well No one has any other questions Thank you very much