 Right, it's time. So let's get started. So my name is Ichiro Fukuda and from NTT and my co-presenter Yuda Iwasaki from NTT, Nachi Ueno from Juniper. So today we'd like to talk about the framework that Gohan and the open source service development engine for the SDN and NFB orchestration. So thank you for coming to the session. So great to see a lot of friends from service provider vendors in this room. So, yeah, what is the ideal infrastructure for us to provide as a service provider to transform our existing service offerings? Deploy the unique and differentiated services in a timely manner and having plug-in open source software and vendors products under service orchestration. So we want to clarify the infrastructure, transform our development culture to DevOps and everything software defined. Sounds good, right? I believe most of the service provider is moving toward the ideal infrastructure as a service provider to transform their business. But what's the ideal, what's the current situation, right? Sorry. The reality, the each pieces are evolving every day. If you look at this week, OpenStack community, it's changing like lots of, like adding new features, lots of cool stuff coming, but it's very difficult. So there's coming from lots of different maturity and functionality. So it's always difficult to integrate and orchestrate to provide a single services as a service provider. So, like before going to the Gohan talk, so this is a challenge in service development. So simply, so, yeah, we like to utilize OSS and standard APIs as much as possible as you do. However, we often face is the feature gap between the business needs and community progress, which it doesn't come to in timely manner when we want to provide a service, integrate to our service offering from the business needs. And another big thing is like a software development methodology has been changed to the Azure. Most of the telcos are like more than waterfall and it's, we had the other ones to have a more long time to develop the solid products and services. But nowadays, we are forced to provide more in a frequent manner to keep updating the feature and the service model to provide our services. So, for example, so back in the 2012 when we started looking into OpenStack and seeing Neutron as a very important component, but at that time, there's no NPS VPN feature set. But we believe that Neutron is a very nice feature, but sometimes it doesn't come from the community when we need to connect our cloud services to the BGP-based NPS VPN network. So this is like some gap between the community and the business needs. So, in order to provide the services in like a transformer of the culture to Azure, so we came up with the code generation method to solve the both problems, what I've described before. So, we have like tools to generate the code from schema to spit out the horizon code, Neutron extensions, as well as the agent code to deliver the BGP functionality to provide like a Neutron-based NPS VPN feature. But we also needed some custom coding to the each code like a horizon Neutron extension agent and deploy. So, this helped a lot. However, it didn't solve all the problems. Something like we still need to have a complex code management and service related codes are distributed across multiple places. Of course, like having those microprocess management is also the deployment of operational difficulties. So, this one is the first generation. We experienced a lot of like having taking advantage by the code generation method, but it didn't, yeah, we had some challenges. So, today, this is the second generation, Gohan. So, this is the, we focused to provide a microservice in a minute to simplify the cloud orchestration and cloud service architecture. So, you can see gohan.cloud1.io. You can see and it will guide you to the GitHub. So, yeah, so, we'd like to dive into the details of the Gohan now. So, now I'm going to hand over to Nachi. Okay, so, let me explain the architecture. I'm from the control team, but actually, I was working for this in his team. So, this is continuing jobs and on the between two companies. So, this is the architecture. So, as Ichiro-san mentioned, this is the second generation of the service generation framework. So, that we could have the sub definitions, including resource schema, extensions, and policy. So, this schema is defined the resource model. And then, but sometimes the only schema is not enough, so you need a custom logic. For example, in Neutron, when you create a port, Neutron will generate MAC address for you. So, something like that, logic is needed. So, we support that on the extension. Then policy, so, just like in the Neutron example, some resources is only limited for the admin role users. And some resources for the normal users. That kind of stuff is needed, so that we have that policy in the service definition. Then, Gohan could have the server mode and worker mode, both same single binary. So, Gohan is using Go language, so there's no, maybe less pain on the dependency management. So, no more than something hell of that deep dependency issue that there's no, this is written by Go. So, that really, this is helpful for the operational deployment. Then, also that this Gohan can understand the service definition described in the top of the there. And important characteristic on the Gohan is it is not a compiler of the service. So, it's not generating code, but it is an interpreter. So, Gohan can interpret service definition dynamically without any binary changes. So, that you can change the, evolve your service very rapidly. Then, Gohan server will push the resource changes to the sync layer. Currently, we are using XED like such as many cool new projects such as Kubernetes or OpenShift or Cloud Foundry. So, they have API servers and utilization layers and workers can understand the update from that city. So, that this is also so called API gateway design pattern. So, we could have some API gateway, we have the API gateway, which will do the authentications and many stuff. Then, it can talk as a southbound microdisk services. So, let me explain four key capabilities in the Gohan. The first stuff is the schema. So, we choose the JSON schema for the defining schema, because this is really widely used. Even it's often stuck using the JSON schema, the API validation stuff. So, why we choose this JSON schema? This is more like application developer's language. So, not only network, but also this is widely used on the application layer. Next characteristic is the policy. So, Gohan support a role-based access control now. So, actually, Gohan can be integrated with the keystone, like many OpenStack components. So, on the authentication, Gohan can get a role on the users. So, based on that role, you can configure the access policy for the API. And third characteristic is the extension. So, now, Gohan support the custom logic using Go and JavaScript on the Gohan DSL. Gohan DSL is kind of like a... You can imagine that we can use a defined API server using Ansible script. So, Gohan DSL is highly inspired by Ansible. So, you know, Ansible hired a defined deployment model using YAML. And that helps a lot, because actually, this big changes between the code and the configuration. So, this DSL enables you to say you're focusing on defining a service, so not coding. The fourth characteristic is the integration. So, as I said, Gohan can be integrated with the HCD. So, you can write a worker, can get any resource updates. So, resource created, deleted. And then, HCD provides some integrity on the resource correctness. Okay, so, let me share the thought on the background for how we design Gohan. At first step is... This is start from the pain on the microservice management, right? So, as a first day, like this is a kind of story, so we have fat service, so fat service are painful. You cannot change up, it is slower your development. So, you cannot change APS servers. Each subcomponent is highly dependent, so you cannot cut out. So, then microservice is meant to solve this issue. But also, it's introduced... Maybe you guys are very familiar with OpenStack, because OpenStack is using microservice architecture. But if you introduce microservices, we should manage tons of the small processes, right? That is pain. Also, the orchestration issue is happening. So, this is really tough challenge to manage transaction between multiple microservices. So, what we are going to propose is having microservice. So, this is not the definition of microservice, but having microservice inside one top of one interpreter. So, we can define separated, clean separated small instance of the microservice in the one process. So, this is one process. So, it is really easier to orchestrate multiple services inside one DB transaction. Also, since we have only one type of the binaries, that makes your operation, the deployment, very easier. So, next step is schema-driven subs-development. So, this model-driven development helps the development a lot. But in the first generations, we rely on the code generation. But code generation gives us more compiled time, management of the generated code, such as so on. In Gohan, we try to be creating interpreter, not a compiler, so that you can, after you define JSON schema, that Gohan will provide you the CLI, web UI, less API, and DB management code, without any generated code. Then, the third point is the background is single place to the defined service. So, when you define service in the typical cloud architecture, we have controllers, DB modules, and workers, and sync layers. But one code will be split. So, that is really hard to debug. So, let's say, if you're going to do something, going to this process, this is okay, and another process, this is okay. Then, worker, this is failing, or this is something like this is happening. So, that in Gohan, we're going to create one single place to define one service. Then, each component can understand each service definition, so that is make your service definition management very easier. Okay, so let me demonstrate a live demo on how Gohan works. Okay, so that this is GitHub Gohan site. So, if you're okay, please start this project on GitHub, because he's Udai, his weekend project gets 5,000 stars. His weekend project. This is my weekday project. So, I really welcome you guys to start on this project. Oh, by the way, okay. So, you can go down. Then, you can see some demo movies. We have some online chats. So, if you have questions, please go into the chat room and ask any questions. Then, we have two ways to start Gohan. One, one easier way is deploy to Heroku button. So, if you click this, you can learn this Gohan, some sample application on the Heroku without no pain. So, maybe this is pretty neat function. Please try that. This time, I'm going to go to the download version. So, you can go to the release page. We pre-compiled for the multiple platforms for you. So, you can download binary with suit your environment. Okay? So, maybe just... Then, after you download binary, you can simply start Gohan server config file and Gohan YAMO. Then, start it. Can you read it? It's small? Something, yeah. Okay. So, go to the Gohan UI. So, this is UI page. This is something developer mode page. So, you can see the schema is defined. Actually, the schema in Gohan defined by schema, so, like bootstrap stuff. So, then let me create... So, let me show some one resource. So, this is a kind of network resource. This is kind of subset of the neutral network resources. So, this is JSON schema. Since JSON is not human friendly, so, we use the YAML format for the main to write down the JSON schema. So, we have network. So, then, let me create a new resource subnet. So, create subnet, singular subnet. We need to define plural form, title for UI, subnet. Then, prefix. Then, we have some different properties in the ID and name and description and tenant IDs. So, this is subnet. Let's add a slider. Then, maybe that we need a reference to the network ID. Network. Network. Then, go to detail. So, this is the detail of the JSON schema. We added some attribute for the JSON schema. So, like for this case, we need to add a relationship between subnet resources and network resources. So, then, we will type relation network. Okay. Then, relation property. Okay. So, let's submit. Then, new resources created. So, let's go to the UI. So, you have the two resources. So, this is kind of the auto-generated UI from schema. Then, create network. Submit. Then, create subnet. Blue. Description. Sider. Network. Submit. So, this is created. Also, that we will provide you to the CLI client. So, go on. Okay. Go on client. So, we have the list of the supported resources. So, we have the network and subnet. Then, go on client subnet. This is so that we have the list of the subnet created. So, just like generating the CLI for any resources. And this is also this client can understand the server-side schema dynamically. So, in case you added new resources, there's no need to delete distribute client. Because client is enough intelligence to understand the server-side schema. So, this is also less painful, right? Okay. Then, so this is how I share how to do that. So, on the GitHub pages, we have enough, maybe not enough, but adding many examples of resource model. So, actually that using this YAML file is really easier for the real development. Because I found engineers really like this text format. So, also the application policy. So, you can define the policies in this form. And custom logic. So, this is an example for the JavaScript-based extension. So, you can add the event handler for the API request. So, in this case, we are adding event handler for the pre-create. So, pre-create means that it will be executed before we store the resources in the database. Also, this one is experimental, but this is Ansible-inspired Gohan-DSL coder, Donburi. So, then this one is just like Ansible script, but you can execute Ansible script on each API, Ansible-like script on each API request. So, in this case, we are creating, when you create network, we can create a control virtual network. Then check the response. The response is okay. Set the status of the network to active. So, this one is... Then, you can also find the Go-based extension in here. So, please read the GitHub pages. So, also, you can use Gohan... You can integrate Gohan with your system. So, you can execute extension on the... So, you can use Gohan as a worker, I think. Also, you can check the AMQP queue on the open stack. So, this is very useful. Like, we can get notifications of the heat resource stack creation using AMQP. And then, after that, you can execute extension. Also, we support SNMP. And we can also do a periodic job called a cool-on job. Then, we have more examples on this Gohan app. So, we have the NetCon for example on the Donburi Plus heat integration stuff. So, we are planning to add more interesting stuff. Okay? So, okay. So, this is the sample. So, let me button touch... Again, please start this project. Okay, let me button touch... Okay, thank you, Nachi-san. I'd like to introduce some actual use cases we are working on right now with Gohan. So, as Nachi-san mentioned, So, Gohan is a kind of service orchestration layer. And actual resources in the southbound need to be created by somebody else. So, right now, we are working on Donburi to directly create southbound resources from Gohan. But it also supports sync layer. So, you can plug in anything, like a worker for AWS or OpenStack or CloudStack or whatever. So, we are using, right now, a heat worker that is working with heat to create southbound resources like control networks or NVF instance or and so on. So, this is our basic model when we are using Gohan with southbound providers. So, the actual use cases, I'd like to introduce two actual use cases. So, the first one is CloudOne, that is our project name, and we are using Gohan in this project. So, Elastic Service Infrastructure is an entire system and Gohan is the main component of ESI. So, in this project, the goal is to make network configuration easier and faster. So, for example, right now, maybe you need to establish a new VPN across your branch offices. Maybe you need to call your telecom company like AT&T or NTT. You need to wait for two or three weeks to get a result. But that is not a cloud way. So, we want to make that procedure more quicker and easier. So, what we are going to do is provide web portal for customers. They can self create network resources on that web portal on their own and the networks will be created immediately if they request it. So, in this project, so, Gohan will provide a web interface like Natchi-san demonstrated. And the third one providers are basically contrary and the users can create contrary resources on that web portal under each branch offices they have this Elastic Service Edge, we call it ESI, and they are orchestrated automatically using Gohan under heat workers. So, this is a very basic use case. And the other use case is Next Generation Cloud Platform. Now, entity communication is working on. So, cloud one team is supporting this project by providing network functionality to this project. So, the challenge here is we need to support a lot of network functionalities. For example, so, of course, we support Neutron API using Contra, but to cover all demands from our customers, that's not enough. So, we need to support also bare metal and NFV like firewall and load balancers. And also we need to support the internet gateway. So, we want to connect VPC of customer to the internet. And also we need to support VPN to allow customer to direct connect between their data center and our cloud infrastructure. So, that's the point. So, we have, of course, we utilize Neutron API because that is supported by other OpenStack component really widely. You can use Horizon, you can use Nova if we support Neutron API on our infrastructure. But that's we need to also support those different component hardware. So, but from the perspective of customers so they don't want to use a lot of endpoint, API endpoint. So, we need to provide a single integrated endpoint for our customers. So, that's a challenge. So, basically what we are going to do is mix up these different... Okay, let me show this slide. So, in this case we have Nova for NVF and Contreras for interfaces for virtual machines. Also, VM servers and we are using also NetConf to configure routers for gateways. So, in this case for example, customers want to create a firewall instance. Maybe they need to attach some port to that firewall instance. But they are basically managed by different southbound providers. So, if this service orchestration layer is a kind of proxy server that just transform message format basically customers need to you know need to know the detail of those different southbound resources. But it's not so straight forward for customers. So, what we are going to do is using Gohan we integrate those southbound providers and customer can use Gohan as a single point of access. So, by using Gohan, it's really easy. So, as I said we need to manage all resource types like NVF and network for subnet in a single point. In that case, maybe right now we have over 50 resource types in Gohan. If we don't have Gohan, we need to write a lot of code to support all those resource types. Maybe we need to write a lot of DB initialization code rest of API code and so on. But with Gohan, what we need to do is just write basically JSON schema and Gohan takes care of API response, DB initialization single layer and so on. So, it's really easy to manage a lot of data types and connect that to the source bound providers. That's basically the advantage of using Gohan. So, I would like to show you some demonstration of cloud next generation cloud. So, in this demonstration, I'm going to create some resources like internet gateway, external and internal network and firewall and so there provided by different source bound providers. In this demonstration, okay, it takes a little bit of time. So, Gohan basically implements Neutron. So, users can Neutron client as well. But this is in this demo created for resource. And also, Subnet is also supported by Neutron client. So, this is really basic use case. In addition to that, this is Gohan client just demonstrated. So, of course, users can use both Gohan client or Neutron client and right now creating some important resource using Gohan client. So, what I want to say here is all these different types of resources provided by different types of source bound providers are operatable. Users can operate those different resources from single point, single client, single API. This is really advantage of the next generation class. So, as Ichiro mentioned, there are gaps between standard open stack process and requirement from actual market. So, we can manage those different speed, requirement, different scopes using Gohan as a single point of service definitions. Right. So, basically what you see is that Gohan we are providing a Neutron plus some bare metal extensions to the model. But as you see, like firewall, NFV services or the gateway services with some IP address lifecycle management or some service provider related operations can be done in a very solid way. So, what we try to do is fill the gap between the open source component, but if we see some gap, we can orchestrate and mix and match the matured product to deliver the services. So, we as a service provider we cannot be like wait for waiting to see the open source components, but in order to accelerate the business we need those kind of feature to build and define our services as a service layer and orchestrate everything. So, the summary. So, the Telco Cloud need advanced networking feature and service orchestration and abstraction layer and we are trying to build our best of breed to develop the heterogeneous environment by utilizing open source technologies as much as possible. But on the other hand we need the agility to fill the gap between the business need and the open source community progress. So, that Gohan was you to cross the chasm. So, we are very early stage of the project but we like to work with you both service providers to come up with a nice service abstraction model and orchestration and also the VNF vendors to accelerate NFV adoption to clarify our Telco environment. So, again so you can see Gohan.cloud.io for the additional information and we are very happy to have any full up conversation through this email address. So, thank you very much and maybe we have some time to take some questions from the room. Welcome, Margaret. So, how do you see this overlapping with Tacker? So, I think Tacker itself, our focus is to as you see, providing service definition layer. So, I think more we are focusing to customize so you can own your model in order to build your service layer. So, I think Tacker is the component that we can consume. But, again, so for the service provider, we need more service allocation to manage our life cycle and also the BSS OSS integration which is not the focus. So, in addition, so we are already providing some our like a billing API BSS OSS integrated REST APIs to provide like a connect back into our service. So, you can define or extend the use cases by using this framework. Make sense? No? Okay. Any questions? Could you use the microphone? So, what do you think about the interfaces with OP NFV? Do you consider to support them? So, actually, currently our team is heavily following the OP NFV progress but at some point, so I think this framework can be used to develop some NFV model layer and so on. Right. So, I think the OP NFV summit is going to have one of the orchestrator session. I mean, there will be going to have lots of presentation from different orchestrator implementers. So, I think I can see that some of the components from your implementation would be useful. So, if you have any chance to drop by the OP NFV summit about the orchestration session, that would be much more appreciated. Okay. Thank you. Yeah. Okay. Looks like time. So, it's end. Thank you very much for coming.