 Our next speaker is Waleed Shari. He joins us all the way from Saudi Arabia and he is going to be talking about NetOps and I'm looking very much forward to your session. Last time if you just came in please move into the middle because people are coming in all the time and we don't want them. Hello folks. My name is Waleed. I work in Saudi Arabia. I am a system engineer basically managing HBC Linux clusters. I started interest in configuration management automation since 2007 with CF Engine. I led the board of concept for Ansible, Bobbitt, Chef and CF Engine on 2012. 2014 led the project to implement Bobbitt Enterprise on the company. And recently I have been approached by the network management team to help them on automation. I have three kids, three lovely kids. I wanted to name them NetOps but the user names didn't allow me. Anyway, so when the network management team approached me I was excited because I love Kubernetes. And in Kubernetes if you are from the variation background, yes there is lots of network stuff going on. The symbol thing is basically the cube proxy and the IB tables. There is an envoy, there is the service mesh, there is STO. There is lots of things that basically I thought okay the moment I am in the network management team I will learn all this stuff and I know what exactly is going under the hood. It didn't happen. So this was my motivation, my incentive to join the network team. But it's my key takeaway. If another team approaches you say yes. The mindset, the opportunities that you will see in a different team, the assumptions that we have are completely amazing. It's completely different. We talk about DevOps but you will not experience DevOps until you join another team. For example, so I presented Kubernetes which is supposed to be a check mark. Each presentation has to have Kubernetes. There is a cat, another check mark. For example, the project Calico. Anybody know the project Calico by the way? So I don't need to talk about it. If you look at the project Calico, this is design and build decisions. It's amazing. When you hear about this the in controllers, I am not a network engineer but when you hear about this the in controllers and about the high availability and you need to make it highly available and it cannot be for the enterprise. As you can see at project Calico, it scales with every compute node you add. Every compute node you add to your Kubernetes cluster or to your virtualization, it basically scales out. And if you don't believe me, listen to the word of the CTO of Bobbitt, Nigel Christen. He says that this year 2013 will be the year of the network automation. And not just network automation, it will be continuous integration, continuous delivery for network. Which is crazy because network is really behind. If you look at, I mean, how many network engineers here by the way? Oh man, I am in the wrong guy. How many operations engineers, systems engineers? You are a systems and operations network at the same time. How many devs? I am in the wrong room definitely. So my disclaimer, I am not a network engineer. I learned a lot about networking but I am still getting it wrong. And I hope if I do anything wrong, if I say anything wrong, correct me. So Nigel Christen basically, he put it really beautiful, put it really nice. If you read it, it's really nice. I cannot put it any other way like him. Last week there was a tech day for Red Hat and one of the presentation by the company called The Glue. And he presented, Sven, he presented the microservices in a very nice way. It's on YouTube if you want to see it. But look at the architecture. We have three data centers. One is for disaster recovery for the spit brain. So it's not really like a data center hosting host. It's just hosting the arbitrator. And each data center has three hosts. Imagine if the number of hosts are 10 hundreds. Imagine if each host has hundreds of containers. What kind of network you will see here? And imagine when the host goes down and the containers need to load balance, what kind of flows will happen? Can you imagine the complexity of the network setup? Who's going to manage it? Is it the developer? Is it the administrator? Is it the network engineer? Who's going to manage it, you know? Probably you guys because if I ask who's the next engineer, you raise your hand. Who's the operation? You raise your hand. So imagine the complexity of the network that we are going to see because of containers, because of microservices, because of the new initiatives that we have. So network automation, the message that I'm going to give you, needs to key up the base, especially in the enterprise. I'm not talking about the cloud, by the way. My context is from the enterprise, physical network switches, physical, traditional network switches. So we need to start the journey. And the journey, we need to tackle three areas. We need to tackle basically the culture, the people, the technology, and the process. The most important thing, this is my third activity related to configuration management. And I know the main failure or the main basically thing that will pull you down or pull you back is basically the people you are working with. If you cannot convince the people you are working with, if you cannot convince your management, your leadership, about the new transition of culture, about the new benefits and stuff like this, your project will not go forward. Technology is very easy to choose a tool. If you choose the wrong tool you have a technical depth, so what? Process will come along. You might choose the wrong process, but then you find out and you fix it. But people you cannot fix it. It takes time to educate people. It takes time to basically transition the culture. So my other takeaway, take care of your people. So what's the context? Where I come from? So basically what I was trying to do, I was trying to give you a blueprint of how you do a network automation activity if you are a system engineer. But I didn't manage to do it. But if you are going to do it, first you need a scope. You need a scope of work. You need to go to context. You need to understand whom you are talking to. When are you going to start? When you are going to end? Who are your stakeholders? And who are the key stakeholders? And what technologies are you going to use? All of these things. So let's imagine that, because I cannot tell you much about the company, let's imagine that there is a virtual Acme company that has a campus which are nine buildings and has a data center which are four data centers. It has a team of five for network engineers and a team of five for cable and access control. The number of switches that they are under control of this management team are around less than 200. But the number of switches that are delegated are not under them, but they have to solve as the first lines of support the issues are more than that, much more than that. So the number of end points is around 57,000 points. They have DNS info blocks. So this is one automation point. They are not using it for automation. They have part of the info blocks. You have an IB address management system. They have a network management system using SNMB. They have been using for a long time the traditional 3-tier system. So basically you have your core switches, you have your distribution or aggregated layer, and then you have your access layers. And sometimes they are mirrored. So basically from the data center to the data center, the core will be back to back. They do lots of changes. They do new HVC clusters, new servers, whatever. So probably every week there must be a change. They do also lots of trouble shooting, perform a trouble shooting. And always there is a new application. Concentrates. In the data center we don't have access to the internet. It's a very linear process. There is lots of controls, especially security-wise. So that's the context. It's a very traditional company with a very traditional team. And they want to start automation. So what kind of automation is out there? Let's say we will specify them differently. So basically you have the CLI. The CLI, this is what Cisco teaches us. Cisco teaches us as CCIEs and stuff like this. If you want to be the CCIE, you have to do things from the command line, serially, one device at a time. So the vendor calls us the problem on automation. Cisco have changed their curriculum, by the way, the CCNA curriculum now, and they have something called programability on the curriculum. Juniper, they have a special course by themselves. So the first one, just basically cut and paste and use it not bad. There is nothing special, very traditional. The second is that we will start using byte and scripting. They're using where all tickle, expect. Some of them using Excel to change the template, to change the configuration. And some of them started using Pubic, Ansible, CF Engine, Chef, Salt, and Stackstorm. The people that started using Stackstorm, they moved a little bit more. They are using Event. So basically now they look at the logs, they look at the SMB traps, they look at telemetry, and they can take action based on telemetry. So this is a step more. There is the new intent-based networking. One thing I learned about networking, they cannot agree on a term. When you say, who knows what SDN means? No, I don't mean... I know what you mean. For example, if you ask two people to define SDN, they will not define it the same. Some will say it's basically an ob... a technology based on ob-flow. Somebody else will say, but you'll have different definitions. Intent-based networks. How many hear about intent-based networks? Okay, a few. So intent-based networks is like what we say in Babit and Chef, and we say the desired state. So the desired state is the intent. But in network, some people take it a little bit further. They introduce machine learning, they introduce statistical modeling. So they want basically to say, okay, this is my business logic, this is my business rules, and now go ahead and do it. So you give guidance, but the actual configuration will come from other methods. And some basically will just use Ansible and say that's desired or intent-based networking. So these are the types. We'll come back to them. So where are we? There's something wrong with this one. There should be an image. Okay, here it is. We are in the first step. We are using the command line because we have CCIEs, DCIEs, whatever. By the way, we are heterogeneous. We have lots of different brand types. We do things serially. So if there is an upgrade for 50 switches, we'll do one switch at a time. But what we do, we open 50 terminals and we can do a little bit quicker. Yeah? So this is basically human-grown. One research, say, from 20 to 70% of blackout errors in data centers is from these methods. I just made it up, by the way. No. So one white box vendor is making fun that the only thing changed in the last 20 years is moving from 10-letter SSH. So why we are not automating? What reasons? The first thing, actually, is the vendors themselves. They are teaching us not to automate. The way they teach us to be really good engineers not to automate, do it from the command line. The other thing is the way we work, operations. It's another technical fact, like DevOps, whatever. Something else will come up. Some people will say, our environment is really complex. We are heterogeneous environment. We are traditional. There is no way that there is a solution that will fit us. Another one will say, it's cost prohibitive. And we are small. This automation is for Google or Facebook. It's not for us. Another one is, we are busy. Come on, let's do a double grade. Forget this now. So there are lots of excuses. And each excuse, you can actually turn it back. Some, the ones that are good, I don't know where to start. And that's why this is presentation. So we have one senior engineer. He tried, actually, to automate things. He was a senior engineer. And he's the eldest, actually, among the group. A little bit my age. So he created a template engine using visual basic. It's a good user interface. Well, it's a really good user interface, believe me. Yes, it's a good user interface. It's good as a start point for myself to get what kind of data they want to capture. But what problems he made? This is a lesson on how to fail network automation. This one. First thing, ask. If you want to develop something, we have developers. He never used any development tool. He never used, like, user interface design or anything. He did everything from scratch, lines, statements. All this design was, like, took him one month to do. He didn't use get. He didn't use length. He didn't use any development tool. Okay? He never approached any developer. He never approached his team. So basically, if you want to fail an automation project, do this. If we failed one activity, so we said, let's fail. I mean, let's start a new one. So we start a new one. The first thing we do, we want to know information. We want to gather information. That's the first thing I really would like to know. So we kickstart brainstorming session. In this brainstorming session, it's actually two ways. It's one way to educate them to basically make them aware what is out there. Another way to educate myself to know what they are doing and what kind of tools, what kind of problems, what kind of time they can allocate, and things like this. So it's two ways, and you have to do this as often as you can. Interviews, shadowing. This is the way you can get more information. Okay? I learned this the hard way. So for example, the word net ops, the word net devops, it doesn't come across them. They are really busy. So you wanted to know, and you wanted to make them aware, when they have troubleshooting for performance or anything like this, is the visibility tool that they have right now, is it enough? What can they do to improve it? What kind of automation they would like? What kind of challenges they are facing? All of this are going to be your task list. So maybe they are using automation already. Like for example, I said info blocks. Maybe some people don't think the HCB is an automation tool. It is an automation tool. You do dynamic provisioning with it and stuff like this, and they are using it heavily for the network access control. They are doing profiling, the board activation, stuff like this is done automatically. This is automation. Automation doesn't have to be using an automation framework. It doesn't. If you are using the vendor tools already to automate your activity using hardware, using vendor software that comes with your solution, that's fine. Second thing, you need to get your management approval. So you need to find what cause or what goal that basically management will buy in and will give you the resources you need. And it's very easy. So it could be a pressing need, something, a project that we need now. Or it could be an opportunity, and we have all of these. So just choose the one that is close to the heart of your management for leadership. So I need a list of tasks so we can start. There is a good community network to code. It's one of the best open source dev-op community I have seen. I ask the stupid questions on this slack channel, and they answer me. I ask it again. They will answer me again. It's really one of the very cooperative. You can ask what is an IB, and they will answer you. It's really a good channel, a good slack channel. So they run a survey, and they're going to run another one actually this year. So in this survey, they ask lots of questions. One of the questions is basically what tasks you want to automate. So if you look, the main ones is basically configuration management. Sometimes we confuse the word automation and configuration management. There was a talk this morning about automation and orchestration. I haven't attended it, sorry. But basically, we sometimes mix up our definitions. So if you look at the first one, archive, backup. That is not risky. That's good enough. Generation, templating. That's good enough also. Deploy. Stay away from this yet. You don't want to do deploys until you master your system, until you know basically what solutions you are going to give them and how to test it, how to validate it before you do writes. Try to do the reads first. Rebooting, yeah, that's excellent. The other ones, forget them for now. Try just to find one task, one simple task to do. Okay? It doesn't work. Every time you go to network engineer, you say, okay, I want to automate. You say, okay, let's start with VLANs. No, let's start with a simple one. Let's read. No, no, no, let's configure VLANs. Yeah? No, it doesn't work. The other one is basically spanning tree. Spanning tree by default comes with the wrong tuning parameters, so you have to adjust them. And this is one of the common issues that we have. The third one is usually firewall policies. Okay? They want to sync them. They want basically to control them in a certain way, granular way, which if they had Calico, it would be done granular for them. They don't have SDN, unfortunately. So you have to barrier to rise. You have to know what kind of task. You have a list of tasks. You have to know what tasks that are highest priority. In terms of perceived value, perceived value to whom? To the team? To the business? To yourself? To the business. If it's not to the business, to the team, to the operations, to the user. Remember, application is king, by the way. Yeah? When we talk about Kubernetes, we don't care about the underlying network. We don't care about the SDN. We care about deploying the application. Okay? So your priority is, does it affect the user? If it affects the user, that's the one that you want to target. Okay? Is it complex? If it is complex, stay away from it for a moment. Is it once a year? Or is it like once in a blue moon? Forget it. So take the tasks that are easy, that are simple, and have the highest business value. Yes? I want to emphasize this. Don't take the hard task. When you automate, you don't have to automate everything. There's something you need to automate. There's something that you stay away from. Stay away from things. Okay. So in the beginning, when I classified the management methods, or management strategies, we said the second one is basically they took whatever we have in system and application, and they use it in network, like Ansible, Bobcat, Chef, and whatever. And it's true. We have a very rich history. Some would say it's fragmented fault history, but I think we have a very progressive history, and it served its purpose. When there is a workflow, when there is a new use case, somebody will come up with a new tool that fixes this. So in system and administration, in system and applications, we have been doing it right. We have been doing it the pragmatic way. I want to emphasize that. But one thing we are missing that network have, we don't have standards. Yes? We don't have specs, except now. I mean, since Bobcat moved from Bobcat 3 to Bobcat 4, it became an official language. Maybe Ruby, I don't know about Ruby. Chef and Ruby, is it a standard? Is it to the Ruby specs language or not? I don't know. No, I think it's one hour, maybe. Yeah, one hour. We have time. So what I'm trying to emphasize here, that we started at 1993 with CF Engine, and we're still continuing with new combination management automation tools in different forms and different ways. Okay? But even when we look at the history of network, they are the same. The people that accused them of being behind 20 years, 30 years, that's not true, really. Academically, and in certain workload, in certain environments, they have been researching the topic since a long time. For SDN, there is a very nice paper, The Road to SDN. It shows basically the research that caused SDN to start. And SDN picked up in April 2012 when Google announced that they have been using it in their data centers in the Open Network Summit. Okay? And Google now said SDN is the default, which is not in the enterprise, but they said that. So basically, they have a rich history also, the network. But their history is mostly academic, protocol standards, which we don't have. When we look at the network perspective, they started at the same year, 1993 with SNMP. SNMP, they claimed that they didn't serve the verbose. They didn't serve the verbose from management point of view. From monitoring, it did serve the verbose to a certain extent. But from management, you never see anybody managing a host or a switch using SNMP. The S in SNMP stands for symbol. It's not meant to manage complex things. Yes? S-flow, net-flow. I want to spend some time on this one. It's not like us. There is software. There is a topology. There is hardware. Automation for the network is not just software. You have really to think holistic view. The ones that are red is actually hardware. So basically, the cloth fabric. Yes? This is hardware. The OpenWRT, the wireless. Okay? It's hardware. I like it. There's the white box and the BK-8. This is hardware. And this hardware actually made a disruptive revolution in the network acquisition. Do you know how long is the refresh cycle for network devices? Do you have a clue? Do you have a clue how long the switch stays in the data center? Five years? Who says five years? On average. Ten years? Fifteen? Twenty? We have. We have fifteen years switch. And we have ten years switch. No, no, no. Switches live. Okay? The average life cycle is from seven to ten years. But you can just renew the support contract. And you renew with how long? Another seven, ten years. Okay? So you have the chassis. It's basically, they stay really long time. And this is the problem. And this is one of the main problems that I want to get rid of. So when you go back, please tell your finance or your planning or whatever, change the retention cycle or the refresh cycle. If you don't have programmable switches, this is one of the challenges that you will have. Okay? The one in verbal, snap route, they are creating switches in containers. Yes? So now that basically your switch will come like a container. You want a new switch? It will give you a container and you run it. Now, you have your tasks. You have your team. You have your management on board. You want to start. Make sure you have a testing environment. Make sure you have a sandbox. Yeah, Gina 3, especially the latest edition seems to be great. VRNet lab is a container-based lab. You still need the images from your account manager. EVE next generation is also good. If you are running Cisco, you have to have the viral images. Unfortunately. This is one thing we need to tell our vendors. Basically, we need to run testing. We need continuous integration and continuous delivery. We need basically to push our vendors to give us virtual images. Okay? How can we learn? How can we test? Again, from the survey of the network to code, you see two views now. I wanted to see which tools are popular and which tools are not. Which tools? How is the awareness regarding tools? So, the first two, get an answerable. You need basically version control and you need an automation tool. The Avstra, the last one, is a commercial, intent-based operating system. It does the whole life cycle from A to Z. You design, you plan, you provision, you maintain your network set up from a single centralized place. It's awesome. There are open source. There are open source tries since the last two years and actually, they were on the last slide. So, we know which tool to go with. Because it's popular, we chose Ansible. Ansible is really doing, is like the main tool for networking, for network. The only tool that is competing with it is SaltStack or Salt. I always call it SaltStack, the company name. Why Ansible? Because people think that it's agentless. Bablet and Chef also are agentless when it comes to network. They will create a proxy and the proxy will talk to the network via ABI, like it's talking to Amazon or anything like that. But Ansible is very easy to learn. Ansible is very easy to deploy. And this is a problem. This is not a feature. It's a problem. And that's why it's a problem. Yes. Because basically, it encourages individualism. It doesn't encourage teamwork. When you use Ansible as a network engineer, you start creating a playbook, adding roles and stuff like this, and you forget about everybody else. Yes? You don't use version control. You don't use anything. So this book, Automating Growness Administration, the author was against these. So if you want to start automating using Ansible, make sure to ensure that there is a collaboration between your team from day one. Make sure that you have version control setup, development workflow. Make sure that you can manage the scale. So you have the best practices in terms of directory structure, in terms of using roles and stuff like this. And don't use roles straight away. Let your team learn basically how to create a playbook first and stuff like this before you move into roles and the best practices that Ansible recommends. Testing. Testing is a must. So, I said we have to choose a small task. So we chose the tool now, but we need a small task. So how do you do it? You look around you. When I start my operation day, what things I do, and if I can improve it. One thing at a time. I don't want to, the network engineer doesn't want to learn to get by the way. The hardest thing they think that it is there. So basically try small things. Small wins. Start with a simple use case. So, the development workflow, our network engineers actually are Windows users. Mostly. They can use VI, but hardly. So, I wanted the workflow that is familiar to them, and that they can learn. So, VS Code. Linux, Windows, Mac. It's available everywhere. And the user interface is fantastic. And it integrates with Git. So basically, it will be like one user interface for them. Yes, and you don't really need to know Git that much. And GitLab. And GitLab will allow them to have history, version control, a wiki for their documentation. And GitLab, 10 especially, is like a full life cycle. And you don't care about the operating system. Even the editor you can use from GitLab itself. So, you can even forget VS Code. And the automation platform, AWX. AWX has surveys, has workflows, has lots of things. So, it will scale up with the task that we will do. So, this is the solution. This is the technology that we are proposing. Okay. So, what's the first thing we do? Editors. They're using Notepad. The moment you give them an editor with syntax highlighting and just a little bit checking. Yes? This is changes things. So, this is the first thing. This is the first way. Okay. So, we talked about the software. Remember what I said? Automation for network is not software. It's other things also. So, what is my recommendation to my team? My recommendation is to take care of themselves. The management. Basically, now we are running Cisco, Juniper, whatever. Why don't we run white boxes? If I run white boxes, I save like 5% of the price. Basically, it will cost me 5th of the proprietary price. Yes? And this saving, I can spend it on training. I can spend it on the team. For the next five years. And actually, I'm not saying that. Gartner is saying this. And they made the statistics. They made the research. So, whatever we gain, on the next five years, we put it back on the team, on the B-Bull. And I found this protocol, which says premium B-Bull requires premium compensation. B, B, R, B, C. Yes? You get it? I have a problem with the B and it's the same. For me, it's the same. Think ahead. So, basically, you solved the technical solution problem. Look at the end. We notice that the refresh cycle is an issue. Okay? Handle the refresh cycle. Because if you don't handle it now, you will suffer seven, ten years in front. So, better handle it now. So, recommend standard hardware, white boxes, open source, open standards. So, you can have whatever protocol you need. If you need NetConf, you will have NetConf. If you need OpenConfig, you will have OpenConfig. If you need Yang, you have Yang. Whatever protocol that comes up next year, three years from now, it's just a matter of install. Not like the traditional devices where you cannot install. Yes? Insist on modern hardware. Insist on quality. Insist that at least you have NetConf on the device. If you are running three tier, ask them. Why don't they run Spine and Leaf? Spine and Leaf have proven to be a very scalable way to increase bandwidth for workload. And most of the workloads are actually east and west. Yes? And the latency is much less. There are lots of benefits for Spine and Leaf. In terms of bandwidth, in terms of automation and stuff like this. So, bring it up. Maybe the next project will be Spine and Leaf. It doesn't have to be the whole data center. Our problem we are the green field data center. We cannot basically burn it and start a new one. But there are new projects. We can evaluate. We can actually test. So, that's the hardware side and that's the software side. And my timer is leaving, so I don't know what time it is. Okay. So, let's do configuration measurement 101. Usually it's desired state and current state. And if the current state is not like the desired state, the controller force it in Kubernetes in any basically configuration measurement tool. Yes? So, the network, how do I get the desired state? I get the desired controller. If I have an SDN controller, I will define my policy there. If it's Ansible, I'll define my blame book there. How do I get the telemetry? How do I get the current state? There are like SNMB, or there is telemetry protocols, or there's NetConf and RESTConf, or maybe Syslog, or maybe other protocol. Yes? Okay. So, this is an example of what IETF is recommending. And the vendor is also, by the way, the vendor is bushing this also. So, basically what they are bushing, they said the CLI doesn't work. The CLI, you have to worry about the timing, you have to worry about the interactivity. You don't know if your Python library needs to be updated for a new switch, for a new version, whatever. It's not guaranteed it will work 100% all the time. SNMB, they say it failed us management-wise. But we took the best practices of SNMB and CLI and we add the network operator requirements and they come up with certain standards. Yes? NetConf, RESTConf, and Yank. What are these? So, basically Yank is a language. A language that describes data structures. Describe constraints for this data and describe what kind of data types. And you can basically describe anything. One example by David Barasso is basically describing Star Wars movie and which actors on the movie and stuff like that. So, basically you can describe anything. You can describe a topology, you can describe the component of a network switch, you can describe the elements of a network switch and so on and so on and so on. Yes? It's meant to be the unified solution to multivinder device discrepancy. That's our hope. It's not there yet. I think, I'm not sure. But that's our hope. But it is the way. NetConf, from the name, NetConfiguration Protocol. Okay. I'm nearly there. NetConf is the NetConfiguration Protocol. It was designed in 2006. So, when it was designed, nobody thought about RESTful at that time. So, it is a little bit heavy. It uses SSH over board 83 and it's meant to create, delete, replace the configuration. Okay. There is another one that is RESTful. It's a lightweight. It's RESTful. It uses RESTful code over STTB. So, it can work along with NetCon. And basically both will use Yang to communicate the data. Yes? This was last week. Ivan Dibnyak, if I pronounce his name correctly, is so frustrated that basically the vendors don't get it yet. You cannot have a device, even modern one, that basically is really programmable. You still have to put a layer on top of it, an abstraction layer on top of it, so that you can actually manage it. It's not just the traditional devices that are a problem, even the modern one. Yes? So, we know this. Yeah? The problem with standards, there is always a new standard that creates another fraction. So, this is an example of how NetConf with RESTConf and Yang will work. This is the architecture. So, let's say you have a client, which in this case is Ansible. I took this, by the way, from Charles. Where's Charles? Yeah, here. Charles did, yesterday, he did an Open Day Light presentation. This is a sketch, and they put Ansible instead of a client, because that's what Ansible does. So, basically, you have Ansible as the client for RESTConf or NetConf, and he will communicate using either NetConf or RESTConf. If it's NetConf, it will be brought 83 over SSH. If it's RESTConf, HTTPS, and it can use multi-heterogeneous. This is a hot-regenious environment. And you have, this is another thing we don't have as system. You have the candidate, the start, and the running configuration. So, you can actually make differences in stuff better than us. Yes? So, NetConf can understand that and can manipulate it. And this is how it looks like. Do you like it? So, this is the same playbook. It will work in a heterogeneous environment. Do you like it? I don't like it. Our network engineer can understand that by the way. This is how it looks like if you don't use the NetConf module. So, basically, you look the line on red. If it's an REST device, you just pass the command as it is. As an initial step, this is what the network engineer is like. They want something that is human-readable and is not in their way. They don't want to change their working way yet. So, start with what they like. To declare or not to declare? So, basically, do you want to use the NetConf? Or do you want to use, basically, specific network commands using Ansible module specific to the vendor? I think the specific to the vendor is actually okay as a first step. One way, one thing that is great about Ansible, when I started using Ansible with network modules, I tried to stick to the supported Red Hat modules. But I had found corner cases like, for example, the CLI is interactive. How do you best interactive command to Ansible? You say, slash NY or what? There are people doing it this way. But there is another Ansible module from the community, from the network to code community. They can do this. When you install a new update or upgrade, yes, yes. So this one will do it for you without worrying about it. There is Nibalam, which is an abstraction layer. And it's very good with Yank. It can actually retrieve some facts and it can write some configurations using Yank. So, basically, this is the abstraction layer for the future, Nibalam. And always hit refresh. So, basically, what you do, you select the task. You start nagging your planners, for example, about the topologies and the hardware. You fix the task, you go refresh. Another task or make this task better. And that's what we call continuous improvement. I'm finished. If you have any questions, please ask. Thank you. The slides are up, by the way. They're already up on the