Hello and welcome again to another episode of For the Journey, our number 4 now we're up to with this hour podcast and livestream where we're talking to IP Fabric's partners and customers about how they're how they're faring up, I suppose, on the on the road to the self driving network. That that network automation, seems to drive us all these days. Today's guest needs no real introduction. If you've been following IP Fabric's journey this year, it's kind of interwoven in particular with, with today's guest. Rich, I'll let you introduce yourself.

Well, thank you very much, Darren. I appreciate it. Thanks for having me on and, allowing me to talk with you about, automation, federation, source of the truth, and all that. My name is Rich Martin. I'm the senior technical marketing engineer at i10chil, which means when I'm not, demoing and doing webinars, I'm having conversations like this with partners, with with prospects, with customers, and with our own teams, to, continue.

And I love this for the journey Yeah. Because we always see this as a as a as an automation journey. And so what we do at i10chl is we have a software platform that enables networking teams to build network automations, because that's always the starting point. And and quite honestly, and you and you know this, the network domain needs more automation probably compared to a lot of the other, technical domains in IT. So that's really our starting point.

But our view of automation really goes beyond that. But we gotta start somewhere. Right? It's about meeting where the cost meeting them where they're at, right, at the at that particular time. No.

That's a great point. I mean, that you hear all this this about when I work automation all the time at the moment. Obviously, it's a it's a big buzz phrase. It's a thing that that people are engaged with and it's captured the imagination, but it can only ever tell part of the story, isn't it? And so I guess that's that's where we have the commonality, isn't it?

It's about being able to say, this is part of the story. This is this is only part of what we're trying to achieve by through automation. It's really about improving operations more generally, I suppose. And and automating not just the network itself, but other aspects as well. Absolutely.

And that is a huge part of what we do is, we have to, you know, we have to meet the customer where they're at. And a lot of times, they're focused on their automation strategy, where they're at in their journey, is focused on where it hurts the most. Right? So if we're talking to a networking team, they're looking at the backlog of changes probably in the data center, but it could be all over the network. And it's like, well, what what can I do to automate all of these steps that that I have to go through in order to make a change?

Right? Especially if it's CLI. Right? Lots and lots of CLI changes. That's a starting point.

But, really, you have to widen that and broaden that out. And so, and and that's walking them through that journey. Right? Where does that data come from? So before you make a network change, that data has to come from somewhere, and it's probably multiple somewheres.

Right? Right. And so what we do is we we want to meet them where they're they're Certainly do the the network automation piece of it, but kind of broaden out that view of automation because it is about automating the process. Option you know, the whole operation, the end to end process. And with that, part of our platform is the ability to integrate with all of those, different systems, both network, you know, sources of truth, IT systems, ticketing systems, all of that.

So that when they're ready in that journey to start broadening out. Right? And there's always different phases. Let's start with the network change. Now let's gather some data.

Let's do things like update tickets, you know, in ServiceNow or Jira or whatever it may be. And and moving forward, building automations that are robust and intelligent that can actually do, like, post check, pre check, post check processes. And as we're gonna talk about today, not only just generating data from different sources of truth probably. Right? But also ensuring before and after those changes that operationally, everything is in line.

Yeah. And then, of course, what do you do when it's not in line? Right? Yeah. Yeah.

All all fantastic points. And and I suppose comes back to that that thing, doesn't it? Everyone says the first thing you do in in when you're building automation is have a source of truth. But but you've already alluded to the fact that, actually, a source of truth might be a step too far. Right?

We we've all got systems already that we use operationally. We we all have as we're as we're doing our network operations, we have our CMDBs. We have our our ticketing systems and all of these things that have data that's useful to create automation, I suppose. So is it sensible then to try and use one source of truth or what what's what's your thinking on that? Well, you know, I think we think very pragmatically.

So so, you know, having a single source of truth, it's kind of like this this this this cycle that we've been going through. So if you if we go back in time in our time machines to the days of the early days of and I'm gonna use this this bad word, SDN. Right? Because it's it, you know, it promised and I worked at another vendor where we had, OpenFlow in our hardware. We had a hardware switch.

We had OpenFlow. We used something called Open Daylight as a, as a controller. And the promise was the promise was one controller to rule all of your networking, which is awesome because then I have a single brain that I can go to that knows about the configuration and the state of the whole network. Right? Well, what happened?

It didn't really pan pan out quite that way. There's a lot of challenges with scalability. Yeah. Some networks are completely different than other networks. Right.

And they can't be modeled the same way. And even look at today. Right? If your network is now, partially in the cloud, right, network teams doing net cloud networking, that's completely different than anything we've ever experienced. But you can you can say that about pretty much any network now.

Right? Because Yeah. Now it's correct. You're absolutely right. There there was that whole I mean, look, you and I, we've been around a little while, right?

Well, certainly I have. I'm speaking for myself now rather than you. So I think I'm giving myself away on that. Yeah. Yeah.

But we've we've seen, you know, we've seen networks develop from a single piece of wire in an office connecting, you know, a bunch of PCs in a server to a situation where all of a sudden you need a dozen servers rather than 1. So you have a data center. Then you need a wide area network to connect to your multiple offices to that data set. So then you need, and so on and so on. And we just exponential growth of the use of IT has meant that we've just introduced complexity on complexity on complexity.

Right? Correct. As a result, I suppose that that that's where the problem start to occur with trying to bring a single view of of everything together. Now I'm I'm I'm not talking myself out of this because IP fabric, it does have that ability to give you a single operational view of what's going on. But that's not what we're talking about at this stage.

What we need to understand is that you've got multiple systems contain controlling certain parts of network. Correct. And those are gonna have the data that you need in order to deliver change and whatever into that into that network. Absolutely. Absolutely.

And so from, you know, from that, the original root of of the idea of con you know, of controllers, You know, we've seen the implementation in smaller domains. Right? So if we look at SD WAN, like like you mentioned, there's a controller there. If we look at, you know, wireless, you know, Wi Fi Net Enterprise Wi Fi, there's controllers there. Even in the data center, you're deploying controllers.

So these kind of controllers help to understand and and integrate with both so as a source of truth, but also as also as a as a way to help with the automation process. Right? But really and truly, we're also seeing a lot of great tools, utilities, systems, that helped the that help, network teams, create, you know, their own databases that are very specific to their types of network. Right? You know, NetBox being a great example of that.

Right? That's what I was gonna say. Yeah. A lot a lot of our customers start off with, like, IP address management because that's kind of the top of top of mind thing. Like, we always need IP addresses.

We always need to assign them. We need to have a we need to step away from the spreadsheets. We need a place to manage them in one place, and this is a great, you know, this is a great tool. But the other side of that tool is, well, they have a lot of data center infrastructure management. It's very flexible.

Yeah. You can go you know, you can define, data center, you know, this row, this rack, this switch, this port, this VLAN. You know, this this VXLAN configuration needs to talk to this server. Right? Going all the way down to that that layer, which now gives you some amazing source of truth.

To the cables themselves. Right? To the cabling itself. Right? So the trick is the if if if network automation for a lot of folks, especially on the network team starts with making network changes, we want to help them understand, well, your network changes has to have data.

So in order to make a change on all these controllers and things like that or even directly to a device on, you know, by CLI. You have to have that data. That data has to come from somewhere. So how do we integrate those systems, grab that data, automate that piece of it, and now take you to that to that step where you can validate the change, make the change, and then make sure and this is the critical piece too. Right?

Make sure that the change does the thing we wanted it to do, we we intended it to do. Right? And that's where we're talking about the state of the network, the actual operational state. And and I I think it's important to make that distinction. Right?

Because because ultimately, you have this intended state. Right? This this this, data that's that's stored wherever it's stored, like you say, could be could be any number of systems or all in one. It almost doesn't matter. But be able to to gather that information to be to deploy based on that and then look to the network itself to turn around and say, well, actually, you know, do these match?

You know, are these are these something that that, has the has the intent of the I see. We use the word intent so much, but as is the outcome of the change? Does it match what the intent is for that change? Like, that's that's for me is the thing. And it's interesting because any one change, of course, has multiple tasks within that change, And each task has its own outcome, but there's an outcome of the overarching change as well.

Right? So so you might pull data from different places for different parts of the change. Let's say let's say you're making a change to to, add a new service into the network. What you may decide is I want a a port standing up on a particular VLAN with a particular IP address for a server to be attached to. I might want to, change a firewall rule so that that server is able to access the auxiliary services it needs and that users on another subnet somewhere else are able to access that service and so on.

And so you're gonna have different management domains for each of those things potentially with different data sources for the data that you need to bring that together. So it's it's this idea, I guess, of collecting the the the the intended state data from multiple places, manipulating them so that they are in the right form to then deploy the change. Right. Right? So it's so it's APIs, data transformation, all of that good stuff going on.

The playing out into the change and then the magic when you're coming back to verify, not just that the individual tasks are successful, but the overall outcome is as well. Right? Correct. Correct. And and and that hits upon broadening that view of what, you know, of what automation really is.

It includes all those systems. Because what's what's triggering a lot of these changes, right, somebody's making opening up a change request ticket, right, in in an enterprise and saying, I need this new service or I need to deploy this new application or I need to connect my, my remote branch to this, you know, to this application. That involves lots of changes across lots of parts of the network. Right? Yeah.

And so having a view of just making a change in one part of the network doesn't get the job done. Yeah. You gotta do multiple changes. And here's the key, When all those changes are done, if the application doesn't is not you know, you can't connect to the application, let's say, from the remote office if that was the request, The end user says it doesn't work. Yeah.

Yeah. Regardless of whether or not it was a network problem, a firewall problem, you know, a routing problem, If it doesn't work, then, you know, you you you you spend all that time Yeah. And and you didn't accomplish that task. Right? So we should be looking at that great overall.

What are all the changes required? Right? And now all of these domains Yeah. What are the sources of data? How do we transform that data to inflict those changes on these different network domains?

It might be a control. It could be in the cloud. It could be an SD WAN controller for your remote office. Could be, you know, CLI changes in your data center, leaf spine switches. All of those things have to be done.

And then at the the, you know, the culmination is, does it work? Yeah. Yeah. Does it work? And and that, of course, I mean, hey.

We'll we'll we'll blow the trumpet at this point because that is, of course, where where IP fabric steps in and and plays plays a huge part. Right? Because we have that visibility across the entire network. So we're able to gather that that a model that view to validate the outcome as being right. This application is is able to be accessed from this location and everything in the network allows it to.

And if it doesn't, if it fails at any stage, we can identify the point at which it's gonna fail. And so and so send triggers back into the automation process to go fix the issue. And Right. And if anyone's if anyone wants to see this in action, we did we had had great fun setting up a demo, right, for for the tech field day at, Cisco Live, back in June where, yeah, there's a there's a really neat demo there. Even though I say so myself, I thought it was, it was pretty Probably it also hits upon all of these things we've been talking about.

But I think that's the important point here, right, is is if this isn't about blowing a trumpet, this is about explaining a problem. Because once you've executed that and the state of your network has changed, you've then got to think about the sources of truth. And and do they accurately then reflect what the network looks like at a point in time? Because, yes, you've you've done the change. Yes.

It's been successful. But there may be changes in the state of the network that aren't necessarily then reflected back into those sources of truth. Right? So then it becomes a decision point. What do I do with this this assured assurance data from the network to make sure that that everyone has that consistent view of of what the network looks like at that point in time.

Mhmm. Decision time. Decision time. So here here's something here's a here's a situation that every network engineer could probably relate to that that's kind of the the smaller scale version of what we're talking about. I'm about to I'm about to provision manually provision, you know, an IP address or a on a port.

Right? I go to the port. It ought to be nothing on it. There's nothing there should be nothing on it. You know, I'm told this is the next port I can use, and there should be nothing on it.

But I get on the configuration. I get on the switch or the router. I look at the port. I look at the configuration. Uh-oh.

There's something on it. What do I do now? Right? Uh-oh. The the link is active, and it's it's it's actively passing data.

What do I do now? I have a conflict. Right? Yeah. I was told this this is the port we're we're connecting up to this new customer service or server or whatever it may be.

I have the data that I need, but something in the actual state is is different. So now I have to go back and figure out what to do. Do we do we define a new port? Is that old is that an old system or service that can that we can overwrite and reuse? Right?

Those things have to be done. We, as network engineers, we've we've run into these problems, the unexpected. Right? And this is, I think, a critical insight because when when folks look at net, network automation, they're looking at how do I automate all these changes on the network, reduce backlog, things like that. But now you have the tools with automation, with sources of truth, and with understanding the operational state of the debt the network, all integrated together to now build automations that help identify these these, you know, conflicts, drifts, and and and intelligently do something about it.

And that intelligence comes from the networking team, the engineers. Right? Right. So it's for us, it's about, okay. We know this is gonna happen.

This is a challenge that's always gonna happen. Why? People. Right. Yeah.

Maybe you love it. Changes. Yeah. Yeah. Yeah.

Yeah. We we all know at 3 in the morning, sometimes you make a change. You have to make a change because sometimes the state of the network is, hey. We gotta get it up. Yep.

Right? And if that change is now not reinstute it reinstituted and updated somewhere in your source of truth. I think I think that's an interesting point in itself. Right? Because here, what what you're talking about is is really and and I don't wanna boil it down to to the d word, but it but it's documentation in in to to some extent.

Right? That's that's what we're talking about here. Yeah. Because that source of truth really should represent the future state documentation of the network. Book.

And and if that's incorrect for any reason, if there's a if if you have to if you have to have have manual responsibility for keeping that documentation up to date, it has a knock on on the quality of your automation. Right? Because Right. Because if you've you've got to rely on the fact, you've gotta trust the fact that that documentation is kept up to date. And and ultimately, that's what a source of truth is.

Right? It's a documented state. So if your process for updating it is manual, then you're, then you you run into exactly this particular problem. Right? So so I guess what we're talking about is as part of your as part of your automation workflow, what you need to be able to do is lift the the resulting state data out of the network and ensure that that that's the intended state matches that, actual state, that observed state.

Right? Correct. Correct. Yeah. That's and everybody loves good documentation when you're on the the the side that needs documentation.

Right? The receiving side. But actually making the documentation is tedious. That's why so much documentation is not updated. It's not done.

It's it's it's it's an extra step. It's a replication of data and work that you've already done. So the with automation, building those things, and again, that's part of the broadening out of the the the understanding of what automation is for for network teams and and all teams in IT, is we should have steps that integrate with that document, that source of truth, or that ticketing system to be able to automatically document that. Because here's the thing, if I'm pulling information from a source of truth in regards to how a particular service needs to be provisioned, IP addresses, ports, things like that, VLANs, whatever it may be, if I already have that in the automation, it's just another step to transform that data, update the ticket, update the source of truth, you know, at a particular step in the automation, and boom. And now automate documentation is not tedious.

It's up to date. Yeah. And I would argue if if if organizations are going towards a single source of truth as their overall strategy, you know, that's gonna be a even a bigger challenge to keep that up to date. So you're gonna have to rely more heavily on automation Yeah. To be able to do all those updates and keep that that it that information is is in sync as possible.

Yeah. And it and it's and fundamentally, from certainly from from my attentional's perspective, we're talking about getting access to that data over API, right? Because that's that's the key to to being able to put this together into a workflow. You're able to access that observe state, as well as the intended state over API and you're able to compare data, do that work to say here's where stuff's gone out of date. And in some circumstances, absolutely, all you'll do is just go back and update the the intended, state.

Right? That that's source of truth. In other circumstances, you might look and say, actually, doesn't look like it looks like we might have to do some more automation to fix this particular state because it's the the sync is the wrong way. Right. So we need to go back and and go again.

And in some cases, it's gonna need manual intervention, and you can't really do anything but, decide, right, that data, I I can't just dump it straight into the source of truth because it needs someone to look at it and to to to be sure what's going on here. Absolutely. But, of course, the the beauty there is because of the way our attention works and because your ticketing system is is is connected to the workflow, you just update the ticketing status, right, to to go and allocate it to someone who can go and do that manual check and then when they've done the manual check, update the ticket and it automatically then goes and processes that update in whichever way it needs to. Yeah. Absolutely.

You've hit upon all of those things. So a so the API integration within Itential, making it easy, making it quick, literally being able to take, you know, an open API spec from a, you know, a system which publicly, you know, published and dragging and dropping it into our platform and generating essentially an integration or an adapter for accessing those systems opens up that all of those possibilities. Yeah. So it's not just even reading data from, you know, a source of truth, but it's also writing data to a source of truth. It's also creating new tickets.

It's updating those tickets. It's you know? And so now, like you said, like, automation still requires the intelligence and the expertise of the network team. What we need to do is allow them to build automations quickly and efficiently to express all of that intelligence, and then then it becomes an iterative process. Right?

Yeah. Because now I I run into these changes or these conflicts between intended state source of truth and what the actual state is. And, you know, we run into these things. Oh, okay. We know how to handle that.

Let's build that intelligence into the into the workflow. You know? It's interesting what you said about the iterative thing there because that because that might got me thinking. I suppose for automation to be fully successful, every step of the automation, needs an automated task, right? You need to be able to to carry that out in in a way where you're piecing together automation tasks in order to deliver a complete workflow.

But there's nothing stopping you when you have the right, approach to having manual steps in there so long as you're able to then trigger, retrigger the the continuation of the workflow. So you could almost Right. Build build the process out. And even if one of the steps might might require a manual intervention, ultimately, where you can get to a point where you've perhaps run through it a couple of times and realize actually that step can be automated. Correct.

You just then drop it into the into the place in the workflow. Right? Yep. Yep. Yeah.

And and and I always think back to the manual process as as, you know, as a network engineer on a network team. As soon as you identify, like, how to fix certain problems, I'm also communicating it with the rest of my team. Like, yeah, we've run into that, and this is how you fix that. Automations for networking team should be the same kind of iterative process. Right.

We figured out how to fix that. Let's check to see if that's the the the the the source of the issue, if that's gonna, you know and you and you basically are detailing that process in your automation. Yeah. It's just so having the systems and then making it easy for networking engineers to be able to do that with a in a low code, no code environment. Yeah.

No. That's really cool. I I I think you've hit hit on something really interesting there, and and I think hopefully, it gives people thought that that idea of, of of having to to validate the data that's that's going to and fro because it's it's key to the whole to the whole process, isn't it? Without without good data, you're gonna get a rubbish automation. So Yeah.

Yeah. We always say yeah. We always say, you know, you need the best data in order you know, as a as a as a piece of having reliable robust automation. Like, you would never automate on stale old data. Like, that would not that would probably not end up in a successful, you know, automation result.

No. And and I suspect that's that's what a lot of people struggle with. Right? Is is, again, you know, if your if your source of truth in the first place isn't in good state, that it doesn't accurately reflect what what, a, what you want the network to be, but, b, what the network has has been previously, you're gonna really struggle to, to deliver anything meaningful. Correct.

Yeah. And you're or you'll always be very limited in your ability to automate. And and it really and it starts to become more like a patchwork of automation with humans, you know, pushing buttons behind the scenes. I can also you know, I feel safe automating this little tiny task. Yeah.

Yeah. Yeah. Yeah. But then when that's done, I have to take the output of that because, you know Or or or someone someone's gotta actually sit there and press the button to to run the automation in the first place and that type of thing. Right.

Right. Exactly. And so it shouldn't that should not that that that is a very limiting thing in, you know, in automation. We you shouldn't have to do that. That's that's not what it's about.

So that's why it's important to have that broader view, to be able to integrate with these systems, to use that data and manipulate it, and then leverage the data anywhere you can as you know, you don't have to do everything at once. But I'll tell you, as soon as we talk to, you know, prospective customers about how we accomplish in you know, making network changes, gathering data, the very next thing is, like, hey. Wait a minute. I spent a lot of time in service now. What can you do there?

Yeah. Yeah. The lines are are widened up. Right? Yeah.

For for me, and this is and and yeah. Because because that's very much the space that that that we have in the conversations with customers as well. Right? Is that there's so much data in the platform and it's in such a strongly structured form. That means that there's so many things and so many people, different groups of of teams.

Right? So so it doesn't have to be the network team. It can be the security team. It can be the server infrastructure team. It can be the cloud team as you've alluded to already.

All of these folk need access to that data. And so if we can make that data available to them in a simple form as possible by bringing it together and combining it, from from whichever sources, then then it's all good. Right? Absolutely. Absolutely.

Awesome. Yeah. And and and then then it's like being able to make your network your your automations more efficient. There's a couple of things there too. It's like, once network teams understand that they can build in, you know, these very intelligent robust automations that integrate sources of truth, data, can can speak to systems like IP fabric to understand network state and validate that, yes, this is working.

Then it's like publishing those automations for self-service catalogs, or maybe the DevOps team is doing some CICD. And now they can build automations and participate in what the rest of, you know, is the rest of the IT org IT organization is doing in in in publishing those those automations. And I and I guess as well, making those the the outputs from those clear as well. Right? By by putting them into, I don't know, chat rooms and and Oh, sure.

Sure. And, you know, those sorts of things and sending emails and that kind of stuff. We're just Yeah. Publishing out the results of that those automations as well. Yes.

Correct. Yeah. Well, I can, you know, I can tell you I was gonna say that sounds like a whole another story. There's a whole other thing, but it's such an important thing having communications between teams. Sure.

Especially, like, with with network operations teams. Right? Those guys are tasked with making sure the network's running, you know. And if you're about to do some work on the network, how often I'm guilty. I'm gonna use myself as the example, but as the scapegoat here.

But how often at 3 AM, things aren't going quite, you know, well, or you've got so much work to do. I didn't tell the network operations team I'm about to start. Right? They should already know. Right?

They should already know. Yeah. Yeah. Yeah. But if I can actually tell them I'm starting, and here's specifically what I'm doing, when I'm doing it, and how I'm doing it, that no not that communication, it makes, you know, everything run more efficiently efficiently.

And maybe, you know, it helps them to understand subsequent impact on the network. Sure. Right? So they can handle that. They can front end any calls that happen.

Right? They don't bother you about it. It makes everything more efficient. So even something small like that. Correlation and all that stuff.

Right? Yeah. Yeah. Yeah. It's a big efficient and it's all about efficiency.

Yeah. Right? And and I think that's the other thing too is it's it's real it's really interesting to see how our customers get very clever and make things more efficient Yeah. In in in their automation. And and something like IP fabric I'll tell you what.

Here's something that comes up all the time, and it's such a simple thing. How do I find a MAC address on my network? Yeah. Yeah. Well, if you're gonna do it manually, right, or even in an automated way, I have to look at the, you know, I have to I have to look at all the the MAC address tables on my switches.

That's one way to do it. So you start logging in and you start Yeah. You start crawling that network because that's the only way you're gonna do it. Is there a way to make that more efficient? I know one.

Yeah. Exactly. So so it's also looking at ways of being more efficient. And when you can become, you know, when you can start tweaking your automations to become more efficient Yeah. You know, over time, again, that's more of a let's get an automation done and now let's, you know Using whatever data sources are available.

And right? It's the thing I've got because and and I I appreciate we're we're we're blowing the time here, but we're we're we're we're we're. Yeah. That's true. I was thinking, you know, you mentioned SDN controllers and stuff before, but you could even regard those as as sources of truth.

Of course. Yeah. Yeah. Yeah. Because what they do is represent what you wanna deliver in a part of the network.

And it may be instead of having a split of certain types of data in certain repositories, what you might have is the same type of data in multiple places depending which part of the network you're talking about. Because, of course, no network is one network. Everything is is a a network of networks. Right? And each Right.

Each domain of the network has its own management approach and its its own processes. So Yeah. Yeah. Yeah. And those controllers, yeah, they can be looked at as source of truth, like, for inventory.

Right? They're going to know your SD WAN controller is going to know which SD WAN routers and devices are on the network. Why? Because it has to be provisioned Right. Through the controller in order for it to actually work.

So, you know, that's and that's something we can access and even relate back to a database. Right? If if you wanna go that route and relate that in going back to automating and understanding the differences between the 2. Nice. That's all good stuff.

Rich, I have burned a lot of your time and I, I I don't plan on keeping you too much longer. I was just wondering if you got any other, any any gems of of, knowledge that you might want to share with people before we, before we stop? Yeah. Well, I I think just kinda recapping what we've talked about. If you're on a networking team and, you know, you're looking at automation, you're probably looking at, you know, tools like Python or or, Ansible.

Those seem to be the ones that always pop up. And there's a, you know, there's a a very big skills gap to learn how to do automation correctly in in those environments. Take a look at Itential. We are custom built and and engineered to allow networking teams to build automations exactly the way you want to translate that info information in your head into a a canvas where you can start to automate across not just your, you know, CLI based network, but through a controller, cloud, wherever it may be, and integrate all these systems. And here's the cool thing.

We understand that integration is a two way street. Right? So if you already have that, you know, that really, that really, rare network engineer who also has picked up Ansible or has picked up, Python and is writing, you know, automation scripts, we can integrate that into the system. So it literally becomes an another step in a task, and so you don't have to throw any of that away. And so it gives you the best of both worlds.

And now now not just that one person or maybe that couple of people on the team that know how to leverage those particular tools can do automation. It's really everybody on the team can now start to use automation and use the tools and the and the utilities and the programs they've already created. Yeah. And that's why we say we wanna meet, you know, those networking teams where they're at, but then we wanna progress them on that journey. Let's let's integrate that all of those sources of truth.

Let's let's make sure we, build the right pre checks and post checks and include, you know, systems and tools like IP Fabric that make that part of it much more efficient. Because, again, at the end of the day, even every network engineer knows it's just gotta work. Right? Yeah. And so when when a change request comes in, the end result is it's gotta work.

It's gotta work the way we intended. Perfect. Great way to close. Thank you very much for your time, Rich. It's, as and I love that you got all the all the buzzwords in that last segment.

And, that is awesome. It's really good. Well, that's that's the the technical marketing The technical marketing engineer right there. In my role. But yeah.

No. Thank thank you for your time, mate. It's always good to talk. Of course. Always.

And, yeah, we'll, we'll hopefully speak again soon. But, Absolutely. That's it for this episode. Thanks. Thank you.

Bye bye. See you.