 All right, let's get started. Thank you for joining us today. I'm Mohan Kumar from KBM Networks. So I contributed to Neutron, Neutron Client, SFC, and Heat Resources. Hi all, myself, MD Nadeem. I am working in Red Hat, and I have contributed in OpenStack, Kola Project, Chakar Project, and in Heat. So we are here to talk about what is Service Function Chaining. So Service Function Chaining is to help us to automatically provision different tenant flows. Without, let's say, for example, if you wanted to treat HTTP user traffic, we need to put firewall or IDS boxes, and we need to configure using VLAN. It's very difficult for the admin perspective, and it's very time consuming. So we have a dynamic way of provisioning using Service Function Chaining. So Service Function Chaining is a very fascinating term being discussed recently. Most of Open Source IASS services like OpenStack, OpenCountrial, ODEAL, VONUS are dealing with this. So in the next 10 minutes, are you going to learn how you're going to create Neutron SFC Service Function Chaining using Heat template? So first we'll cover a little bit of background about Neutron, Service Function Chaining, Heat and Hot Template. Then we'll see how to create a DevStack environment, and we'll discuss to have a short demo to look and feel what are the concepts we have explained. So here you would see that architecture, all the SFC building blocks are highlighted in LO blocks. So at Neutron Server, we have drivers, extensions, and plugins being defined. At bottom level, we have compute node with OVS and OVS agent. This OVS agent will directly speak with SFC driver and help us to download SFC flows. So we had a first release at February 2016. We are part of Neutron Stadium project, and Heat Supporters was added in Neutron OpenStack release. We also have Pluckable Service Function Chain, driver architecture, so we could play any SDN controller and we could create a SFC data path. So we also support dynamic service function chain, optimization, and deletion. I am going to give a brief introduction about Heat as most of you already know about it, and I will show you what the Heat resources is needed to get an up and running SFC environment. So as Heat is an OpenStack orchestration tool using which you can deploy almost all OpenStack resources that you need to have an up and running cloud infrastructure. So Heat have mainly two major component. One is your Heat API that will take the client, request from Heat client, and there is an in-built Heat translator within the Heat API service, which actually pass your Heat template and provide the information to the Heat engine via MQP message bus. And Heat engine is solely responsible for creating your requested resources. Like using this, you can create your Nova server, you can create Neutron port, or you can create any Cinder volumes. So Heat mainly support two kind of data format. One is your YML, other is JSON, where YML is most recommended and mostly used template format. So Heat template has six different section that we will cover in details in our demo section that will be specific to SFC service. So to get an up and running SFC service, you need to deploy four different Heat resources, that one is your port pair, another Heat resources is your port pair group, port chain and flow classifier that gets into details. So to get a service function instance, you must need to create a port pair corresponding to each service function. So in port pair, it's nothing but a Neutron port, where you need to specify your ingress and egress port corresponding to your service function instance. And then the second one is your port pair group, which is nothing but a collection of port pair that is give you, that is help you to mainly scale your service port instance and you can even distribute your packet load via port pair group. And the third one is your flow classifier that is mainly define the traffic flow and on the basis of your source and destination combination. So like there can be multiple possible way you can define your source IP, destination IP, source port, destination port. And the last one is your port chain, which actually define the sequence of your port pair group and using port chain you can link your port pair group to flow classifier. So to give it a try, you can simply pull your heat master branch then you need to enable the networking SFC plugin into your DevStack configuration file and then to create a stack, you need to actually create the networking underscore SFC.yml file. The content of this file mainly have all the four heat resources that I have mentioned in the latest slide. Yes, last slide. We will see the content in later slide also. So we'll see, yeah. Thank you Nadim for the wonderful introduction. Let's see what's the bare minimum hot template we should have to create SFC resources. So first a port pair creation. I said we should have a resource and the resource name I put as port pair one and that namespace OS neutron port pair and corresponding parameter we should pass. I have created two port pairs, port pair one and port pair two for service function one and service function two instances. I said Nadim, earlier we have a port pair group for dynamic load balancing. As of now I'm not interested into any load balancing stuff. So I'm creating a dedicated port pair group for each port pair. Also I have flow classifier which I'm interested in to ICMP traffic with a source IP address dot 31 and destination IP address dot 34 with oxygenator from logical source port P1. So the port chain should have corresponding port pair group and flow classifiers. So for demo we have four different VMs, one is source VM and one destination VM and two service function VMs. Let's see how ICMP ping traffic being treated with service function chaining and without service function chaining. So with service function chaining it should be directed to service functions and without service function chaining it should directly send to destination. So for demo as I said we have a four VM, source VM, SF1, SF2 and SF3. So I'm sending ICMP ping traffic from dot 31 to dot 37 VM. So let's see without service function chaining it should directly goes to destination. So I'm also capturing TCP dump on service function instances. So this service function instances would not show anything. So let's see what hot template, SFC hot template contains. So as we already list out that like bare minimal requirement I'm exactly put the same requirement here and I'm going to create SFC stack. So let's see that should not be any pre-existing SFC resources. So port file is not showing anything. So these are the port list I'm already created P1 to P4. So each one represents one service function. So I'm also capturing flow rules on compute node. So I'm creating stick hat hit stack and stack name followed by template name. So it takes some time to create. We should make sure that creation successful. So let's see what hit list for time consuming. I'm just for running my thing, okay. For hit stack so it should so is so a create got completed and traffic should be originated to SF1 and SF2, let's see. So this port file list it should created that hit stack in background should create all that neutron resources required. So port file list and port change list should have corresponding instances. So a port change list should have a port pair group and corresponding flow classifier. Now we can see that traffic is redirected to SF1 and SF2. So corresponding flow rules got downloaded into OBS. You would see push MPLS, pop MPLS. These are very specific flows to SFC. So for any queries, please reach out at us. We just be here. So please reach us. So these are the references and thank you.