 Are we ready to go? Good? Okay. Okay. Great. Hi, everyone. Welcome to the CTO Perspective Service Function Chaining. We have a great panel for you today and what we're going to do, I'm the moderator. I'm Wendy Carti and what we're going to do today is we're going to start by having the panelists introduce themselves and we'll do a little bit of Q&A here for about 20, 25 minutes and then we're going to open up the last 10 minutes to the floor for Q&A. Unfortunately, we do not have mics on the floor so I'm going to have to run around a little bit especially if you're on the back. So please be patient in that process and we'll make sure that all of your questions will get asked. So with that, we're going to go ahead and get started and we are going to have the panelists introduce themselves. So, Pare, would you like to go first? Sure. Hi, everyone. Clues, CTO and co-founder at Plumgrid. At Plumgrid, what we do is we focus on creating SDN solutions for private and public clouds especially now with the movement of NFV focusing on service instruction and some of the topics we'll cover. Before that, there was a distinguished engineer at Cisco and in there, it was architecting some of the network functions especially the ones related to security, high performance firewalls, intrusion prevention and it came up on the topics that now we are going to debate a lot very close in terms of how those network functions have to integrate and I guess we are going to discuss today on the topics that we didn't solve back then and now some people are solving them in the community and how this is shaping the industry of the network function virtualization. Thank you. I'm Joel Halpern, distinguished engineer with Ericsson. I've been building routers and routing systems for a very, very long time. More recently I've gotten involved in SDN in its various aspects. I'm a very active member of the IETF service function chaining working group where we're trying to define an interoperable data plane solution, interoperability being the keyword in almost any IETF work. I also do policy work and other related things which all are part of making these solutions actually work for us. I'm with Intel CTO for the data center network solution group, it's a little bit of a mouthful but what we do is we work on the whole stack for SDN and NFV from the manual areas, open stack, open daylight where I actually am on the board and the TSC. Also co-editor for the network service header draft in the IETF, the same work group that Joel is a part of so we are involved with service chaining implementation from standards on one hand and code that runs either on an SDN controller or on servers. So hopefully you guys are going to enjoy the panel today. Great, thanks. So we're going to start with just maybe providing a rough definition of what SFC is and I think most of us understand it as a way of doing service stitching for VNFs that you can then create and deploy on demand. You create the service graph that is used for various VNFs. Is that the right way to think about SFC or should there be other ways to look at it? So the way I tend to look at it is it is particularly focused on service function chaining is about applying network functions, capabilities in the network to data traffic that is addressed to other endpoints. So for a traditional NFV deployment the packets are addressed to the function with their packets from the user or packets from one function to another. In the SFC case we're still talking about mostly virtual functions. Obviously we allow legacy functions and we allow physical functions but we're mostly talking virtual functions but the packets we're handling are those from the user that are intended for some other endpoint in the network but we want to apply services to them in the middle of the network. That's why the phrase service insertion is often used. The point of service function chaining is to direct the traffic to the correct places. Having tried to build solutions that inserted traffic control in previous incarnations it was a nightmare. People do it. Lots of people have service function chaining solutions right now and they have all sorts of difficulties. So maybe we can use the slide because I think we may go back and forth to that slide just to help those who have not seen it before understand what it is doing, the way Joel described that and then how it relates to OpenStack and some of the challenges and all of the many opportunities that we all have with this kind of a technology. So simply by ways of introduction of this slide as you could see here we have some clients or some consumers or some entities that could be your cell phone that is trying to actually reach out to some server that provides whatever service could be simply you are trying to serve the net for something. From the operator point of view before we allow you to do that we need to do many things. We need to make sure you have been authenticated, you bought that service, you are not posing a threat to the network and so on and so forth. So when your traffic comes in I want to potentially send the traffic to all of those little stations that are going to do different things for their traffic. I could do something very simple, I could say oh that person has node 7 before there is a problem with that device maybe I could do some video but I need to actually make the best adjustment for that characteristic of the device in terms of the video quality, the drivers on it and so on and so forth. So the red traffic may go and do some type of series of checkpoints or processing while the blue one may have a different one depends on the service you are doing. Before we had that and that actually slide Joel is with Ericsson as he pointed out and the first place I have seen that slide was from Ericsson that idea that the red as an example goes through all the stations but the blue doesn't is right there a big saving because I don't, before I know the traffic I'm going to send each traffic to all the stations meaning I have to set up my infrastructure for peak on all the different things I'm doing with this I'm actually setting the infrastructure sized the right way for whatever pieces of traffic each of those need to see. There are many other challenges and opportunities here we'll talk as the panel progresses I don't want to talk for too long of a time right now so bear it. I will just say a little bit what Joel was saying is that network service function chaining it's a concept right is the ability to create services beyond the traditional forwarding capabilities of networking and what happens is that in the industry what we try to do is to add new capabilities like security, scalability of applications and things like that and if we add them from a policy point of view since there is a business case to be made about that what happens is that implementations go ahead of standards and this is where definition starts to diverge there's a proper way properly sanctioned by ITF and standard bodies that are going to define how to do things but then there are the realities in the ground it's like when applications get deployed when network functions get deployed people want to stitch them and what you have is a community of vendors providing network functions that some of them may support the proper metadata some of them not some of them may have legacy ways of thinking and it's an interesting aspect on how the community from a standardization point of view evolves and the deployments and the prototypes and the early production environments happen because both things kind of fit on each other as we learn more from real deployments and from standardization so now service function changing I think is kind of widely accepted as one of the fundamental elements that has to fuel this new evolution of networking in service providers from the ability to create new service model marketplaces and things like that and I can enjoy all that both things are important and sometimes it is more complex than the proper way of doing it and now we have to figure out how to take that as fast as possible so that's a brings a good point so if you were an open stack operator and you want to do service function changing are there considerations and how one should look at how to stitch these functions together are there you know at these topology base how do you decide how to define that flow through your virtual topology so the way I tend to think about it I think this is helpful for most people you first define the services you want to deliver what functions you want applied to packets and so one of the first things that open stack becomes responsible for is to make sure those service functions are available in the network so if you need more of them make sure they're available if you if for other policy reasons you want them in different locations open stack has the mechanisms for deploying that so open stack drives that and then mechanisms like service function chaining from the IETF and the NSH header allow us to flexibly forward the packets to the places we have put them arranging things so that we have an efficient placement so that the open stack techniques know where to place the functions so that we can efficiently deliver the packets that is a complexity that we are beginning to address but the standards aren't even talking about yet but what NSH gives us is a mechanism to specify the sequence of delivery independent of the underlying data center or even inter data center topology so we're not bound by the physical topology much the way when you use neutron to create an overlay network you're independent of the underlay network but in this case you're creating not just connectivity but a forwarding sequence using NSH and you drive that from a classifier which puts the NSH header on the packet and it lets us put in metadata one of the problems people talk about is but all these service functions are too closely coupled well first off do some design work so you can cut them and then use metadata to enable you to carry information along there so maybe you could elaborate on NSH a little bit more what is that work service header no such header you mean so before before I go to NSH I and this diagram is going to serve us in order to really follow some of the work we are doing with NSH I want to first point out few additional aspects that are related to open stack and the way it deals with this so first of all I'll start with the notion that this is potentially exactly was that example of your cell phone trying to connect to some internet service this is an end-to-end architecture you could actually deploy it not that anybody is doing it today and Joel mentioned people are doing it in proprietary ways right now but you could actually deploy it beyond the boundaries of a given open stack deployment so while open stack would many cases be geographically limited this is not so you need to think about it first of all from orchestration point of view as I need something top down that is able to understand where I want to deploy what pieces of my service now let's confine our views just to that open stack instance within which I would like to deploy potentially the whole service potentially a section of that service I have multiple service functions here you see service function one and two on the slide I first of all need to understand what amount of traffic what amount of processing I'm gonna have there it may mean that I need to have a way to sometime and Joel was talking about placement and we do not necessarily have easy answer to that right now within open stack my ability to say I'm going to place these two next to each other we have zones and things like that but it doesn't really make it easy for me to express what are going to be my h.a. requirements what's gonna be my scale up or scale down requirements and do I really want these two service function to be on the same platform in the same rack so how does the logical architecture relate to the physical architecture more over if you look at neutron and you're doing some sort of a logical network overlay or whatever you want and and NSH and we'll get into NSH next is kind of an overlay approach so how do I actually make sure that I even have the bandwidth and what happens when the traffic really gets much higher and now I have to traverse multiple nodes and I don't have a way to control that so so the normal way we deploy is like we are okay we are always over providing over provisioning of the bandwidth is the way we actually do this so I don't need to worry about that if you really have data plane intensive activity you better be aware of that so there are some challenges here some of them come from the telco world some of them so I have a larger scope some of them come from the fact that open stack is individual VM slash container where is not really providing a good holistic placement or control or management solution for a group of VMs or containers and then I simply don't want to take too much time I'm happy to continue to NSH but yes maybe before we go into the NSH I mean sometimes service function chaining it becomes an overload term in the sense that is is a mechanism a mechanism to basically wire things together based on some sort of policy that is going to classify traffic and send it how to carry metadata in a way that you can compound the capabilities of multiple of them now the question is what's the use case why are we doing that and a lot of times people associate NFB with service function chaining us as one and the same as the ability to solve all the network function virtualization problems of the world but you have to always think that this is a mechanism is a way to as Joel was explaining before redirect the traffic based on certain requirements policies use cases that in a way that you are going to enhance the value that you wanted to offer in that service if you focus on that then those clouds that have nothing to do with networking network function NFB that could be let's say an IT cloud an IT cloud where I have my containers and VM workloads running an Apache web server doing some sort of shopping basket and now suddenly I want to secure it and I want to secure it in a way that I don't want to alter the topology of that application so then I could express a policy that redirects the traffic into a firewall and if the travel firewall may be transparent you send the traffic back and now suddenly you secure your application so somehow the mechanisms that SFC provides they can be used for many things and this is where the placement aspect becomes relevant because if you think in this case the picture that you have in the whiteboard clients and servers are on the sites and then your cloud is running only network functions this could be an NFB use case using SFC as a mechanism to solve the problem and now you'd schedule the days with traffic basically the traverse of all these functions is proper you go to another completely different use case which is I want to secure my VMs running in open stack now the placement of those network functions may be fully distributed in the computer themselves or they may be centralized into an array of things so the the mechanism that we are discussing when you see pictures like that they feel fairly straightforward you stitch function A with function B with function C based on short short of redirection you carry metadata but then you have to tie the placement and the optimization and the scale out of those network functions to the specific use case that you are driving and this is not necessarily only for the NFB community for service providers it's the ability to enhance your capabilities to your applications regardless of what's the use case that you have in a cloud and open stack is one of the main drivers for those obviously interoperability is extremely important between different VNS from different vendors as well as SFC and how perhaps vendors might implement NSH I hear open stack IETF all being mentioned and I know there is Etsy, OP, NFV, open daylight there are many groups manual on the orchestration side e-comp right there's a lot of different initiatives it seems like between open source initiatives and standards activities and maybe you can shed some light in terms of you know it's an open stack operator how should you be looking at all these different initiatives and how do you track all the development and all the definition perhaps that's going on between all the different groups you just want us to spend a minute on NSH intro before we get into a topic that we cannot get out you mean? So this slide is gonna be your quick guide to NSH there's much more to see about that but you could see few of the key architectural components that we have over there as an example we have two classifiers here when the traffic enters into the NSH domain the first action you take is to classify it which really means having the ability to decide what subset of my traffic should be subject to what policy that I have may have set aside which is going to determine what services I want in what order and then I would subject that subset of my traffic to a given service path that here is exemplified by these colorful snakes that are connecting the different service functions but the key element in the architecture that is dealing with the forwarding decision is the service function for the that is an element that understands that apology NSH is transport independent which really means I could stitch together different pieces of the network where I have this service here and that service on a completely different transport it is kind of think of it as a service type of an overlay so I create myself a little service domain and that domain that really sits in this particular diagram between the first classifier the outbound of that first classifier to the outbound of the second classifier which is optional is really my domain and within that domain everything is being forwarded by those SFF and I could have native service functions that are aware of of the NSH NSH has a specific header format the header really carries the information of the path that you need to traverse but that is only understood by the SFF a service function is like the model is go create your service function create your differentiation and the NSH architecture is going to make sure that the right traffic is plugged into it you don't need to worry about that as a service function provider but in the transition as we go into this type of standard based service functions I may have some service functions that are not aware of that header yet and for that piece we have created the notion of the service function proxy that really sits in between and would absorb those packets that have the headers strip them off provide a native packet if you want to that service function and on the way back would encapsulate again the header so just a two minute intro to the way the architecture works and anything you want to add so I believe you touched on it but I want to make clear the net effect is that NSH creates an overlay structure we use the transport mechanisms that exist in the data center whether they are neutron transports or even lower layer transports to provide connectivity between the SFF so the NSH header represents the forwarding within the overlay that represents the service chain that we're sending the packet along the service function path to be more precise and has an index even to represent the position on that path and one of the nice things that does is if you have either a mixture of data centers or a data center that is itself using a mixture of transport technologies you can still run NSH over the whole thing and run the different transports as you've chosen so it works with your data center infrastructure your networking but creates an overlay that delivers service function paths and maybe one more point that is on the slide but we forgot to mention is the notion of the metadata and the metadata as you could see in this example we have DPI as the second function obviously it's just some sort of an arbitrary position but the key idea of the metadata is that you may have already accumulated some understanding that has to do with a particular flow set of flows a particular packet whatever is the right granularity for your case and instead and that's another saving that that architecture provides instead of having to recreate that in each and every station because I don't know what is the policy associated with it or I need to actually send it out of band so while I show you a nice data plane story there is a complicated control plane because I need to time it in the right way or a new flow just started and I need to make sure the policy shows up exactly the same time so the service function would know what to do should I drop this type of packet should I note all of those kind of things you could embed in the metadata few of those things and we have few structures it's not the time and place to go into the details but just to give you an idea and so when we talk about the way OpenStack supports these kind of things we are kind of raising here issues of placement of SLAs of QoS of the ability to actually define the policies externally and inject them into the data plane the ability to create metadata and how this is supported and as a community we have I think some future progress we could all do in order to support all of those and so if we take that and we talk about the question that Wendy asked which is how do all these open source and standards components relate we've been talking about the data plane standard we're going to define somewhere control requirements but then if we're going to get interoperability if we're going to be able to use either OpenStack directly or ODL or ONOS to control these we're going to need interoperable control interfaces and control abstractions in fact arguably more than the control protocols it's the control abstractions we need to get so that the different mechanisms can all be manipulating the same behaviors in a consistent fashion and there's a lot of work to be done on that and it's collaborative work between the open source activities which are moving these control activities forward and the standardization activities which provide a way to actually define abstractions that are useful for more than one open source and so it's that feedback between the two sides it's going to lead to stronger solutions that can get all the way from the policy definitions and the orchestration control down to the data plane behavior you need and taking a more practical approach and echoing what Jolie saying is it's good to start thinking these abstractions and how to map them to the multiple ecosystems from an open source point of view and how do we start converging them being a small company what happens is that now you start talking to customers to different projects and everybody has a different flavor of those orchestration environments and they all have their slightly different models and integration requirements so if we have to move this community forward we have to start creating a value out of these technologies and these mechanisms we have to make sure that we don't start sprawling in terms of control structures and model integrations otherwise we cannot follow there's too many of them we have to test too many combinations or too many requirements that come so we have to figure out how from an open stack point of view which kind of is the centerpiece that is being used not only from infrastructure service but going into all pnfb and into all the nfb environments as kind of a standard environment for the virtual infrastructure manager how now when we start growing up the stack and we are starting to find the frameworks that are going to manage those network functions and orchestrate them how we don't overlap between projects and especially because now we have here the big 10 with lots of projects one of them is aiming at service function training and service instruction but at the same time there's a lot of service providers working on frameworks that are going to define that too so basically the aspect that we have to bring is how do we bring the definitions from the standard and the models and the abstractions from an API that we are going to create and now maybe we are a little bit more loose in terms of what's the right piece of code to implement a specific model a specific API because otherwise we are going to get caught into too many of those and we will not be able to manage the complexity that arises from that so I'll give you a somewhat different take different cross-section of the way the industry looks right now starting from silicon because we make a little bit of silicon here and there there is support in in network cards there is support in switches that you could find in the industry for the frame format of of NSH it also takes a slight variation of the popular VXLan something called VXLan GPE because VXLan didn't have a next protocol field to it so we had to change that so I do have basic support in multiple companies actually silicon when you start looking at these switches life starts becoming a little bit more interesting there is a work in progress in OVS this is work in progress for long long long time and maybe one day we'll get there there is full support today with FDIO actually we have few talks on FDIO here in in this event including one tomorrow if you're interested to learn more about that supports SFC with the NSH format going to SDN controllers there is support in open daylight fully compliant with the IETF going to OpenStack in OpenStack we have few different initiatives right now and as Joel pointed out what we really need to enable let many flowers bloom we need the right obstruction in place we have all sorts of bypass and the main path is partially supportive while I think the high-level good news is that there is an industry momentum towards convergence and it looks like eventually everybody would agree that NSH is the way to go today with neutron I cannot really directly control and manipulate an SDN controller like open daylight that has that capability we do have Techier as a big tent project that works around that and and kind of behind the scene connect the dots so that we could do this but your perspective everybody here may have different perspective whether this is the desired outcome a good approach or a patch what is really I think the question in front of us is what is the right standard main way to do these kind of things and then going to the next level up if you think of the service as something that starts with some sort of a management and orchestration which is a man or from telco Etsy point of view then maybe it all has to start at the top where I actually have a global picture of my topology I have understanding of the consumer and all the entitlement or lack thereof that that consumer has and how all of that applies and some pieces of my solution may be proper pure SDN some may be open stack and I need to stitch that together so that's a snapshot okay so we only have about maybe at most five minutes left any questions from the audience please raise your hand and I'll walk the mic over anything if you could change those questions in the service way service function chaining for questions okay okay because no one ask any questions so I'll ask one there is a Geneva protocol which sounds to me like it could fit both the overlay tunneling and the service here is what about that so there is a proposal that I have seen in an internet draft to put all of the NSH information into Geneva TLV is but speaking personally I much prefer to carry the NSH header as payload in Geneva so Geneva is a valid transport but if I want NSH interoperability it's much cleaner if I keep the NSH header intact across each transport yes there are ways to encode service chains into MPLS label stacks there are ways to encode service chains into Geneva there are ways to compose service chains into V&Is but if we use the NSH we can get interoperability without trying to get M squared mapping at all the boundaries so while you could embed it in something else and there's guys who want to embed it in Ethernet source MAC addresses and lots and lots of answers in fact that's the problem there are way too many answers and instead of trying to say well this is the definitive transport well you build your network one way he builds his network a different way I prefer to use NSH as the commonality and use the transport mechanisms that the network wants to use. Just one short comment while I fully agree with Joel here you need to this I'm putting an ITF head on you need to distinguish because open source we could do you need to distinguish between service function chaining and the different transport mechanisms that are available there's only one proposal in the service function chaining workbook today and that's NSH. There are multiple transport options Geneva is one of them that actually there is a design team that is in formation right now as part of the NVO3 workgroup to resolve that issue regardless as Joel pointed out this is a proposed mechanism would be good for all of us not to argue on on bits and pieces but to agree with something we are all gonna move faster and then maybe let me take a different approach to the answer here there's always the notion of headers has to have to be standardized because multiple devices have to interoperate at the same time we are working towards a new generation of type of data plans that they are programmable. The programmability may be driven because hardware is becoming more flexible or the programmability may be driven because networking is happening more and more into the edge of the network in the compute nodes where you have more tools in terms of software data planes programmable data planes and so on so from a practical point of view we are we are a small company we are a plant grid of course we are not a plug as influential into standard bodies as we would like so somehow we have to be kind of followers and always react towards what the industry defines so we took an approach saying well headers are like very very very strong positioning when you start thinking that you have to burn it into an ASIC but if you have the luxury to have a programmable data plane now the question is how do you react fast to the standardization efforts in a way that you can track them almost like the draft is done and you have a data plane that matches that implementation and doing a mistake is not a big deal because you can change it so in this way it allows for a much more interactive thing for example Joe was saying what if we use NSH values translated to TLVs engine if or we put it into a payload you say well why don't we try both and why don't we see which one carries more things than that so we had to take this approach more from a survival point of view but at the end of the day what happens is regardless the way you achieve a consensus on what's the way to go by the option or by a standardization standardization has to happen and now the thing is like how careful you are defining those headers versus like try and fail fast and that will be based on the implementations that you have available okay do we have time to do one more question I think so yeah hi just a question on them obviously with service trading we're introducing a lot more east to west traffic so from your point of view what solutions are you looking at from a security perspective now we've got this lateral movement are you introducing like micro segmentation I mean how are you dealing with that aspect because that's the issue that I see with all these different points so if you're gonna introduce things like Palo Alto or some you know inspection traffic what do you how are you dealing with that maybe let me start on the use case going back to what I was saying before is when you say how do we deal with security east west traffic means that you have a use case in mind let's say that you have different tenants running different web applications on your cloud and now you want a micro segmentation solution that when you do service chaining using the mechanism of chaining functions you are going to carry the information of the identity of the compute workloads that you have into the network functions that you have and this is what where the metadata comes handy because once you decided that you're going to standardize your service function chaining with a specific mechanism now is the orchestration aspect on how your container or your VM running a website is stuck in a way that when the overlay is going to inject the metadata it carries the metadata in a way that Palo Alto can consume it for example and now standards are important because if one network function vendor consumes dot one qtax versus another one and such headers now the plumbing infrastructure the SDN layer or the physical network layer that has to do the plumbing becomes much more complicated so today this is the reality where we are different network function vendors are providing different mechanisms for integration and the micro segmentation companies like what Plumgrid offers into data centers have to deal with the complexities of the wall so we have to figure out how to accelerate as fast as possible towards a standard like NSH and a proper integration model in a way that the network function vendors can integrate can develop one standard and the integration models become cleaner and then you can attach it to micro segmentation you can attach it to interfaces to whatever you want because this is how you hook the mechanism to identity of the workloads that you have in your cloud so let me just add to that one of the things about the standard as opposed to a solution that somebody might sell is we have to recognize the range of needs if a traditional IP service provider is doing this to add services in their data flow then they are operating within a trusted network they're not worried about securing the traffic against adjustment by the elements of their own network not everybody has the set that security assumption other people have different assumptions so there is a draft for example that's chose how you can add an authentication information to the NSH header to authenticate the header and the content if you want to protect it from modification but the default case you don't use that you use because there's a cost to authenticating and reauthenticating and adjusting the signature when information metadata changes and all of the other things you need to do similarly you could split your service functions and have one for each subscriber and if a subscriber is a major tenant maybe that's the right granularity other times you will want multi-threaded service functions and you trust them enough for them not to be adjusting the metadata that identifies the tenant because you as an operator work with them and make sure that they're trustworthy and so there's different environments and different solutions and different degrees of security and when you're shipping things between two data centers maybe you want to protect it with IP sec even if you're not protecting it inside your data center and that again because that's a transport becomes a solution you can apply in conjunction with NSH okay great I think that's all the time we have Uri, Joel, Peret, thank you very much for being part of the panel I also want to let the audience know if you'd like to learn more about the topics this is an excellent book it just came out called network function virtualization a lot of the topics are covered here we have two copies of the PlumGrid booth so feel free to come by and for additional information on NSH you can also just Google IETF, NSH and the draft IETF will pop up and you should be able to get the entire draft in terms of how that works so thank you very much and have a great conference thank you thank you thank you guys thank you