 Okay, so I think we'll get started here. I think, let's see. I think we'll let everyone kind of come in still, that's out there. Mike is a little loud, I think. So welcome to this session on intent and SDN-driven service chain. I'm Kyle Mestri. I think anyone who's here earlier knows who I am. I'm the neutron PTL and chief technologist of open source networking, not network at HP. So, go ahead, Dave. Nice thing you said. Yeah, I like that. It's like, we're all about network. Dave Lenro, I'm from HP also, and work in the CTO's office in HP networking. Yeah, hi, my name is Kai-Zi Zhang. I'm a principal engineer at Huawei, USA. I'm going to start first. So, what is service training? By service training, what we mean is that through service training management and control platform, different traffic flows can be auto provisioned to go through different sequences of service function, service function chains. For example, for tenant's eighth flow, it will go through a firewall, a net, a firewall, an IDS, a video, and a load balancer. For tenant's B's flow, it will go through a net, a firewall, and load balancer. Even for the same tenant, different application flows can be steered through different sequences of service functions for different types of service function treatment. So now let's look at what is service training from the data path perspective. So, on the open stack management plan plus SDN control plan together will automatically coordination of all the data plan components and program those components to steer different flows through different sequence of service function paths. And those data path components include the class file service function forwarder which can run on virtual switch or physical switch. And then a bunch of service function devices can be run on VM or on the physical device. So why do we need service function training? Because service function training can be used in many scenarios. One of the scenarios is it can be used in public cloud. For example, as this diagram shows, you know, like one video flow from one client look at the pink path will need to go through a net and then firewall and then video optimizer and then load balancer to reach a video server. And then the same client's email flow might need to go through another service sequence for the server treatment. For example, you know, the red line shows the path. It will go through a net, a firewall and then mail security service and load balancer to reach the mail server. So for another client's flow, which is a database access flow, it will go through a net firewall, load balancer to reach a database server. Another use scenario of service training is in the hybrid cloud. You know, when the private cloud does not have enough resource to serve attendance request, it will leverage the resource in public cloud and then there will be communication between the private cloud and public cloud. So for the data traffic from private cloud to the public cloud, those traffic will need to go through encryption. And then for some other traffic, besides going through encryption, also need to go through a one optimizer and then a load balancer. The other direction when the data is shipped back to the private cloud, it will need to go through a firewall, IDS, intrusion detection service, IPS. And sometimes they need to go through a cache so that it's saved in the cache. And then the next time the private cloud doesn't need to access public cloud, just access the cache. Another use scenario is GGSN, mobile wireless scenario. So either from iPhone, iPad, or laptop, when the user need to access the internet, it's the traffic you already go through GGSN, PGW. And then from that, different types of traffic need to go through different service chain paths. Like, you know, those green box shows a service node. For example, some of them could be parental control and others could be like, you know, some security boxes. And so what's the benefit of the new service chain solution? Why we need it? We know that, you know, in existing service chain deployment, it's usually done through a manual configuration of all the boxes. And then that will require advanced business planning. With the new solution, the service chain can be automatically provisioned. And also, we will provide a simple user interface for the user to specify the service chain requirement. It will be an intent-based interface. So it will be a simple user interface. The user does not need to do manual configuration on all the boxes along the path. So that will lower the operational cost and also increase the agility of deploying a service chain. So also another aspect is, you know, in existing solution, when you want to change, when the user change a service requirement or need to scale out, then, you know, those will really require reconfiguration of all the boxes. So in order to avoid that reconfiguration, which can happen for weeks, then, you know, we have to plan for the peak to allocate peak capacity. But with the new solution, right, because all the service chains are automatically provisioned and the data path components are automatically programmed to set up the service chain. So any change of the service chain requirement can be done in real time. So this will lower the capital expense because we do not need to plan for the peak capacity. And another benefit is high performance. In existing solution, you know, the existing boxes are not all, you know, application aware. So usually, you know, we provisioned, you know, all application flows belong to the same tenant to go through the same service chain path. With the new solution on the service chain path is application aware. So different types of applications for the same tenant can be customized to go through different sequences of service treatment. Now I'm going to hand over to Dave to talk about intent. So, you know, we've decided that we wanna have certain subscribers or tenants get certain services and they're described by something called a service chain, but that still leaves the question of exactly how do we build that and how do we put it together? And I wanna talk a little bit about what we mean when we talk about intent and then talk specifically about how this applies to service function chaining. And so, essentially, the spirit of the intent approach is to tell the network what you need rather than what we've done traditionally, which is tell the network how to do it. So historically, we sort of build a model of the network that we want and we describe that to network equipment and that results in supporting our applications. The intent-based approach isn't really about describing the network, it's about describing the applications and modeling their behaviors and their interactions in a way that allows some smart piece of software that we might call an intent engine to do the translation from the what you want to the how do I do it with the current infrastructure. And it turns out that once you kinda define intent, it has some interesting properties that make it valuable for describing what we want out of networks and the goal of a lot of the work that's being done across several open source projects and standards development organizations and things is all designed to converge on sort of a universal language for intent so that all kinds of different applications can describe what it is they need from the network in a common language that can be implemented by multiple infrastructure controllers. So rather than having a kind of a traditional vendor interface to a vendor device and the resulting vendor lock, you end up with a common agnostic interface that works across a variety of equipment and in order to figure out sort of what is intent and what isn't intent, there's some kind of simple tests we can do and the first has to do with the fact that the intent is invariant with respect to the state of the network. So if your high level intent is that Bob should be allowed to connect to the internet, that doesn't change because one of your servers went down or you changed protocols on a device or you bought a router from a different vendor or any of those kinds of implementation details, the piece that's the true intent and the piece that's truly portable and invariant is this description of Bob wants to connect to the internet and assumes he can somehow resolve what Bob is and what the internet is. So that the portability point is closely related, I won't belabor that, but intent doesn't include any references to addresses, protocols, VLAN headers, media types, vendors, anything that's specific to the implementation, it's purely about how do the entities connected to the network communicate with each other and what do they need the network to do for them. It turns out it's highly scalable because it's position and location independent, you can take the entire description of the intent for a network system and you can pass it to one giant mega controller or you can pass it to thousands of small, smaller domain controllers. The information that needs to be sent to those devices doesn't change at all and they can use their local context to figure out how to translate whatever the intent is to the specific rules and implementation details of the devices they control. And finally intent brings context when you're looking at requests coming into a controller, asking for various things. If you go down to something low level like an open flow type of protocol and you try to figure out when things are contradicting each other and aren't consistent, it's essentially impossible to do because you don't have any of the what are we trying to do context, you just have the what are the match and action table look like context. And so by working in the intent space where we're understanding higher level things, the internet, Bob, the secure servers and the finance department, that context can come into the automated resolution of that and help contribute to understanding whether ultimately whether the controller should say yes, I'm gonna do all these things for you or no, I'm not gonna be able to. So just some kind of simple examples and from everyday life, I think I want my headache to stop is intent. Give me to aspirin is prescription. There's lots of things that might help your headache. If you narrow it down and say the only thing I want is aspirin, you actually take off the table all kinds of wonderful opportunities for getting rid of your headache that have nothing to do with aspirin. And so the intent, that's kind of the idea is let's give the automated infrastructure as much latitude as we possibly can to make decisions about how to fulfill the intent rather than assuming that the end user knows how to fulfill the intent and could possibly understand the state of all the equipment in the system. Similarly, when you want someone to cut your lawn, you ask them to cut your lawn. You don't give them a map of every blade of grass on your lawn and some specification for the length to cut it to. Just kind of the high level what I want. That's what we're trying to get to. And what we're doing with this across some different organizations is trying to create sort of a common interface that will be infrastructure agnostic and be uniformly implemented across a lot of things. And so in the ONF Northbound Interface Group, we're working on creating and approving some level pieces of the information model that would describe what this interface wants to look like. And then several projects downstream are gonna consume those software artifacts. In the case of the Open Daylight, it'll consume those as Yang models. In the case of some other infrastructure, it'll be translated to some other kind of format that's understood locally. And we'll end up with this single information model and sort of conceptually identical interface running in the Open Daylight NIC project in the Onos Controller project in a OpenStack Neutron based implementation which Kathy's gonna talk about in some detail as part of this presentation. And on whatever common infrastructure controllers emerge, the idea is to get kind of a network effect and get enough things working through this scheme across different pieces of infrastructure that it draws in more users and more applications and more use cases. So we end up with kind of a common interface to collapse all of this. So when you talk about service function chaining and where's the prescription and where's the intent, it really comes down to the forwarding graph description talks about the kinds of virtual functions in terms of their behaviors and what they do, it doesn't refer to specific instance of a virtual function. If there are 10 virtual machines running a firewall, the intent-based approach says, I want it to go through a firewall. The prescriptive approach says, I want to go through firewall number seven. And the problem that arises with this is it essentially becomes a question of where do you handle errors and faults and where do you do self-healing in this automated system and what's the appropriate layering and partitioning for that? And what I'm gonna suggest is that when you have a low-level event like a network link going down, that doesn't change anything about the forwarding graph. If what you've said is the people in the sales group need to go through the auditing system before they can access the blah, blah, blah server, that doesn't change at all based on how many instances of that you have or those levels of detail. So what we're trying to do is capture pure intent, which is what are the things that need to go through the service chain and what kinds of virtual functions exist in the service chain? And then we hand that to a northbound interface that can then resolve the rest of the details. So that intent-based interface inside the controller in sort of a black box, that's where you're gonna know about the fact that there's 10 different instances of that firewall and where you're gonna get to make a decision based on some higher-level logic. Maybe it's proximity to the subscriber's point of attachment. Maybe it's based on the utilization of the links between the virtual functions, a number of things, but you allow the latitude for the controller to apply all the things it knows about the state of the network locally and then if there's some fault, like a link goes down, the controller, without having to go back and have any interaction with the cloud management system or the upper layers of OpenStack in this case, it can go ahead and pick a different instance, change the forwarding rules and the switches, fix the path so that the virtual function continues to work and between saving the latency of going up to another control system and back and the complexity and the amount of logic involved, you end up with a much more seamless, self-healing kind of a behavior and you end up restoring the customer's service much more quickly. So if you just look at some common things that can happen in the network, if you have the prescriptive interface, you end up with a sequence where basically, outside of the network controller, you try to harvest lots of information about the state of the network, then you try to make decisions about which piece of the network to use and then if something changes, you go back to the cloud management system which has to try to pull all the state out of the network again and try to make this same decision over again. It causes lots of distributed state problems that are hard to solve and it causes a lot of overhead and errors. So here's just a simple table showing kind of with the prescriptive approach, there's a whole bunch of errors that can occur, all of which are gonna cause you to go back through this long, painful cycle of having the orchestration system try to suck all the state out of the network and make sense out of it and then tell the network what to do where when you go to the intent-based solution, what you find is that the network controller can completely heal all of these kinds of faults locally without having to have any more interaction. We've really cleanly layered network-based faults and decisions that require deep understanding of the state of the network, stay inside the network controller and things that have to do with the high-level business purpose and the interaction of the compute and storage and network, those stay in the open stack domain. So for an intent-driven service graph approach, we still are working in the community to try to kind of pin down exactly what the info model is and what the syntax is gonna look like, but the basic model is it's based on these ideas of groups and so a system administrator or some piece of automation would start by building a database inside the infrastructure controller of endpoint groups that it knows about and some of those endpoint groups would be specific to different kinds of end users who might be subscribers of virtual function services. The other kind of endpoint groups become the pools of virtual function resources. So you might create a firewall type A endpoint group that maybe has some firewall appliance that's less secure than the firewall type B, which would be a separate endpoint group, but those become the pools of virtual functions that the network controller has at its disposal to try to satisfy the forwarding graph requests. And then during the life of the system, you can, as the orchestrator needs to scale out some virtual function, it's gonna add a couple of instances of firewall type X and what it's gonna do corresponding to that is add them to that firewall group so that that's its way of letting the network controller know that it has a larger pool to work from and some new candidates to assign things to. So essentially where we're trying to get to is the single intent-based API that comes from a common source and a common definition that gets built on multiple systems. In the case of the Open Daylight NIC project, a service chain user would sort of speak the northbound interface to that SDN controller directly and would get intent-based service function features through that mechanism in a system that didn't have a standalone SDN controller with that intent-based service chain API. That would be sort of the right-hand diagram where actually the upper layers of that intent engine would be implemented as extensions to the neutron system and Kathy's gonna talk in some detail about a proposal for building those extensions into the neutron system and thus supporting the intent-based service function chaining. So we know that in existing OpenStack, the core infrastructure, there's no support for service chaining. So in order to add the service chaining feature to the OpenStack infrastructure, one way is to extend the neutron API to support the service chain. So there will be a neutron API extension to support service chain. And besides that, we also need a common service chain driver API for the different drivers to hook up to implement the service chain functionality. And on top of that, we have this intent engine which will provide the user with intent-based service chain API which Dave already talked about. And then that intent engine will translate the intent-based service chain API to neutron API extension for service chain. And another part is that, currently OpenStack support a few service functions like firewall as a service, load balancer as a service, and VPN as a service. But there are many types of service functions which are not currently supported by OpenStack. For example, like an IPS, IDS, and parental control. So those service function will be created, instantiated by third parties service function manager. So how we can include those service function into the chain? And in order to include those, we have to provide a common API for third parties service function manager to register their service function information so that those service instance instantiated outside of this OpenStack infrastructure can also be included as part of the service chain path. So now I'm going to talk about little bit more in detail about the neutron API extension for supporting service chain. So suppose a user like a service chain from a traffic source to this traffic destination to go through LB, firewall, and VPN. And before on calling the neutron API extension, the user needs to first create those service function instances, create a firewall instance, load balancer instance, and the VPN instance, and also create the neutron network subnet, and then associate those instances with the neutron network. So after that, then the user can specify the service chain specification at this neutron API layer. So this layer is now the intent layer underneath. So there will be two parts of specification. One is the chain path, and the other is a chain classifier. So the chain path will suppose here, the user has created the two LB instances, three firewall instance and two VPN instance. So the user need to specify the neutron port for all these instances. And this information will be passed down to the control plan. So let the control plan figure out what exactly service instance to use based on network proximity, load status on the service function instance, and some other criterias. So besides specifying this chain path, the user also need to specify what kind of flow will need to go through this chain. So that's the chain classifier. So basically composed of a source, n tuple specification, the destination n tuple specification. Here this n tuple could be on any descriptor. You'll say, okay, a finance department is a source. It could be said, the engineering department. So it's not necessarily those network descriptors. So we mentioned before that we also need to provide a common service chain driver API and so that different drivers, so that we do not need to write a service chain driver for different types of service chain API for different drivers. We need to have a common service chain driver API that will pass the information down to the driver layer, for example, OVS driver, so that it can start implementing the service chain path, the data path. So here's a common service chain driver API and then it's very similar to the neutron API except that instead of the neutron port information, it will translate from that neutron port, it's going to get the service functions, locator, information and other information associated with the service instance and then passed it down to the driver layer so that it can set up the data paths. I will also talk a little bit more about the service function instant registration API. So as we mentioned before, this is used to integrate service function instance instantiated by third-party service function manager into the chain. So because the service instance information is outside of the open stack infrastructure, so in order to chain that in, we need to know what information, we need to know the information associated with that service instance. For example, we need to know all this type of information, like what kind of service instance type it is, is it a firewall, is it a parental control, is it an IPS? Also service instance flavor, even for the same firewall, it has different flavors. Also the locator information, the load status on that service instance and also the service instance group for load distribution. For example, you can create five firewalls and they are part of one load balancing group so that the control plan can automatically load balancing between these firewall clusters and also decide which one is the best to use to serve that service chain path. Also the service instance chain correlation method, basically this information need to be collected and passed down to the data path so that the switch knows what kind of chain identification method the service function instance is using so that it can communicate correctly with the service function instance. For example, if it's use vLine to identify the chain, they need to communicate use vLine. If they use the IETF new service chain header, they need to know what kind of chain correlation method is supported by that service instance so that the switch can be properly programmed to communicate with that service instance device. Yeah, so here's the information about this service chain proposal. It's open for discussion. It's not like finalized. So everyone interested in this feature is welcome to join the meeting discussion and then contribute and also post your comments, give your input and ideas. Yeah, that's, thank you, I think that's all. Can I take questions? Yeah, this one, the neutron thing, right? No, no, no. Yeah, here, not necessarily, this neutron port can be identified, can be associated with MAC address or IP address or vLine ID plus MAC address. Okay, so I think here, the neutron port, because currently neutron already have an entity called neutron port besides subnet network and neutron port. So this chain will be based on the neutron port and will assume the user has created a service function and that service structure has attached to the neutron network through that neutron port. But the ways to identify that neutron port could be, it's not necessarily like a MAC address. It could be any address that's associated with that. This is not a classifier. The classifier is on the left side. This is to specify the service functions. For example, in this diagram, it's a green box. So what kind of service function the traffic flow needs to go through? This is used to for specify the service function. In terms of the traffic flow, it's on the left side. So how you specify the chain classifier? How you classify the flow? For example, you say on this engineering department flow need to go through. So that's on the left side, engineering department flow or you say like a finance department or you say a group of people. Yeah, that's what we specify on the left side. The right side, the chain pass is for the real service function instance chain. Okay. But I think maybe... Yeah, different service functions instances will have different ports. Yeah. And do they have to, it can be a cluster, right? But then in order to reach that instance, you need to have a port, neutron port on the neutron layer, right? Because neutron layer, you have a network and then you have all the VMs attached to the network. Each VM will have its own port, right? If you have the same port, then you know, in order to identify with the LB1 or LB2, you need to have a way to identify. That will be virtual interface another. So we need to extend that. If that's because you need to identify the instance, you cannot just say send to all the firewall instance, which, you know, you need to identify to pass that information down to the control plan so the control plan can figure out. Yeah, I think one of the things that creates confusion in this area is, you know, we could talk about layer seven or layer four through seven service function chaining. And what that means is that we use layers four through seven to classify the traffic and understand what source it's coming from. We then use, as you said, pure layer two traffic to steer it through the service functions, assuming they're layer two attached and they're referenced by MAC address. Similarly, if they were layer three attached and referenced, it would all be layer three forwarding. So we're doing layer seven forwarding with either layer two forwarding or layer three forwarding. It's a little confusing, but maybe that's where some of the confusion comes from. Okay. John, can you go to the microphone, please? I think we want to get it on audio. Or we can, we'll repeat your question. We'll repeat your question. Or you can go to the microphone. Can you hear me? Yes. Yes, so my question is about the endpoint groups which you were talking about earlier on. So in this later part, we've been looking at what were classifiers, which were basically looking at the packet headers at different layers. And it seems to me that your endpoint groups are actually a much more useful abstraction than assuming we can grab that information out or anything that's in the packet itself. Because we may have duplication of MAC addresses, IP addresses and all that kind of stuff. So it seems to me that, I guess that's my question. How do you answer it? Yes, I think we're finding that the group abstraction is really important for getting to pure intent. So the intent is that the things in this group behave this way with respect to that group. The fact that there's things called classifiers and layer three headers and layer seven, all that, that's implementation, which by definition is not intent. So we've sort of teased the two apart just so that you can have a pure intent API where you don't have to know anything about how you identify that endpoint. And then there's a separate service which is the endpoint registry or has a name similar to that, which is when you go to actually implement the individual policies, the way that the rendering engine, which is what we use to describe the thing that converts pure intent to the switch rules, the rendering engine needs to know how to classify the endpoint, because that's the thing that's actually gonna see the traffic at an edge, encapsulate it and send it downstream. So we leave the, how do you identify that traffic out of the intent expression? The way you put the whole package together is the intent engine has to go to the endpoint registry, which will then say, here's the mask you use for your five tuple classifier or however that engine behind it is built. But I agree, I think we get completely distracted and we have highly variable information baked into all of our intent expressions if we don't tease them apart separately and that's why it's designed that way. It's a good question. Yes. Well, so the notion is that the intent engine has an interface where you ask it to do things and it either says, yes, I'm gonna do that because I know based on the state of the world that I can fulfill that or it says no, that's an error. Sorry, can't help you. And then obviously there's the case where the network state changes unexpectedly or asynchronously and so there's gonna need to be sort of a callback mechanism as well to say, I promised you I was gonna give you X but the world changed and I'm letting you know that you're no longer receiving that service. Again, I think there's either a synchronous error returned or there's some kind of an asynchronous event that tells you that your promise was broken but I think there's in sort of pure promise theory there's the idea that you don't need any of that overhead because the system will just perpetually try to fulfill the promise which is fairly useless for building an SLA around the fact that it was perpetually trying to give you your SLA values while dropping all your traffic really doesn't meet the needs of most operators. I'm gonna ask you to repeat that once before I try to repeat it. I see. So really this is a data plane agnostic proposal and should support all of the different encapsulated and unencapsulated schemes which really deal with that issue. As long as the data plane bookends the encapsulation and strips it off before it reaches the endpoint, you'll get the original source and desk addresses undisturbed similarly if some other non-tunneling scheme decides to overwrite them, you better put them back before it's done but all of that is sort of orthogonal to this which is really just the control plane proposal and doesn't actually get involved in the details of how you build the data plane. I think we got one more question. Me? Yeah, hi, thanks. So two questions. First is this sounds a whole lot like an effort that's been underway for about a year called group-based policy. Could you please comment on how the two differ? That's the first question. Second question is how are people actually gonna deploy this? As I sat here listening to this, I was just withering under the complexity of what you were trying to describe, not to mention all the complexity that already is inherent in OpenStack networking. DVR, OVS, OVN, holy smokes, who is gonna deploy this? This is crazy. So the first question was how does group-based policy fit into this world and where does it live in this space? And I think the answer is it is one of many different intent-like projects that are being done in the world. And one of the things that we've been doing and I've been pushing through my role as the chairman of the Northbound Interface Group in ONF is to try to get all these projects to work together on a common intent interface in such a way that they can still bind their different implementations to the backend and compete over who can fulfill this API the best but we get agreement and concurrence on what the API is and it's portable across all kinds of infrastructure. So currently in Open Daylight, we're finishing up building an instance of the intent-driven service function chaining where we use the group-based policy implementation as the backend implementation. We're also working on another version of it in the same project that we use the VTN backend to implement the service chain and we expect there to be several others. So group-based policy is certainly a part of this story and fits into what we're talking about but may not be the top layer API that most people see if they're looking for portability. In terms of how you deploy this, what we're expecting is there gonna be two camps that form. There's a camp that says I use an SDN controller which is a smart standalone autonomous black box that hides a lot of this complexity so you never have to know anything about it. You just ask the SDN controller to hook up these magic service chains and life is good. The other camp is gonna say we don't believe in the SDN controller or we can't or we won't deploy that particular packaging so we're gonna do all this using the neutron code that's part of OpenStack and I don't have a good answer to how that's gonna reduce the complexity on the OpenStack side. You're right, it's gonna make a already complicated beast even more so before we're done unless we can come up with some really clever abstractions to hide all of that. But I've probably already shown my cards in terms of which camp I come from but that SDN controller is gonna be really easy. Thank you. Just one last. So let's use the mic guys. So just one request I think after seeing this it would be really good to see a life of a packet or a life of a flow, a little bit more detail as well as looking at some functionality with an NSH header capability to actually show some real life events. I think there's a lot of confusion here that was brought up. Blueprints and such related to the neutron proposal are gonna be discussed in neutron meeting next Wednesday and that that's probably a more appropriate format for the deep dive. Friday. Friday. But the day in the life of the packet probably better for that audience than this one. I think we're a couple minutes over. Thank you all for coming. Thank you.