Okay. So considering that we've got a few topics to cover and 58 minutes, let's get started. So just to to let everyone know who's joined, firstly, thank you all for joining. The session is being recorded, and we will share the recording afterwards unless it's a complete disaster, in which case, of course, we'll edit a few times, and we might share pieces of it. So thank you all for for joining the the first IP Fabric and Ask, Ask Community Fabric Webinar.

We've got a great great panel here to discuss some of the key themes that we wanted to pull out, including our very own Darren Fulwell, IP Fabric Network Automation Evangelists, CCIE and CCDE, Orhan Ergun, CCIE, CCDE instructor, Gianpaolo Borino, CCIE and Cisco champion, and, of course, Julien Monton, network solutions architect from Airbus. The focus of this webinar and the the thing that's really driving IP Fabric these days is the ability for our platform, our users, and everyone to come together within the community and to we really take pride in in helping users and getting topics out for discussion in this first community fabric webinar special. The the focus of this is actually for you guys to be asking the questions and for our glorious panel to be answering. We've got the themes, but if you wanna drop any questions into the q and a function as you go through, I'll introduce some of them in for a live, q and a response and may just type back to some of the other questions as well. So please feel free to raise your questions.

The crucial topics that we're gonna start on and look to work through in open in open discussion are the adoption and best practices around network automation. It's a topic that lots of organizations are looking at. How do we adopt this in order to streamline management processes, reduce some risk, alleviate some pressures from our teams? So the panel will take a look into best practices here and how to get started. This will naturally drift into the theme of intent based networking, which is being hailed as the next evolutionary step in networking.

So we'll take some thoughts from the guys on what intent based networking means, and is it a fad or is it the future of networking? One crucial, point that we see with a lot of our customers but also in a lot of projects, is around data democratization. Once you have a great view of data, what does it mean to use that data? How do you augment existing practices or feed this data into other systems? So we'll talk around once different teams can access this data, what is the value that it can bring?

And, of course, we'll look to close. As long as the conversation doesn't run on too long, we'll look to close on a view of, of future trends. We'll take a look at what's on the horizon for network management, how are different organizations taking a look at this, how are these guys looking to drive their own understanding and learning towards these future trends as well? So without further ado, I'll be, watching the the q and a and look to introduce some questions. But why don't we, get started on a simple one, guys?

Why why automate? You yeah. What a what a great open. I look look at the smiles straight away. It's that whole, that question.

From from my perspective, and I'll I'll dive in to start because I'm clearly the the noisy one. It's it's really key to understand, from my perspective, how we can improve the the experience of designing and and maintaining networks. Right? And and so automation takes a number of forms to help us with this. Right?

It's not we can we can automate the configuration, and we can automate the deployment of networks. And that is obvious. Right? Because that's in a large scale network, it's gonna save you time. It's gonna save you energy and and so on.

But there's there's more to it than that in my head. As much of it is around how we take the data that comes from our network and we use it more widely. So so, you know, network automation, we've been told is zero touch provisioning and it's, you know, controllers and SDN and whatever, but there is a whole load more to it than that. Is that that's fair. Am I right, guys?

Yeah, Darren. For me, I will not talk only about network automation, but connected connectivity services. Because in fact, we don't automate only the network, but potentially a larger set of services. You can automate the DNS. You can automate, I don't know, firewall at the same time.

And what we if we need to automate, it's because we need a business, and we need to deliver something to our business. And for me, it's a key to deliver faster in a consistent way when we need it. And I would say if was your business I don't know if, the cloud team need a network, they don't need faster in a specific way, but they need to be there to have all in one. They all not only expect the VPC, but you will expect, I would say, a larger scope. So I would say not only network automation, we are just a part Yeah.

Of a whole approach for the business, for the company. Yeah. I think that's fair. Shambhala, you you've you're sort of involved with deploying, automation for for folks. What what do you find them using?

Yeah. There are I think there are different levels of maturity for automation because, most people start with simple tasks, simple repetitive tasks like creating a configuration, creating a new DNS entry, something that is manual, that can be easily automated is the easy win, and then as experience grows about coding, about API, we can have larger and larger tasks to be automated. So and teach is good and can be the final goal because it saves a lot of time. It allows us to have consistency between the configurations. So it is a very nice goal to reach, but, the next step, the next maturity level is orchestration.

So we don't see the network as a single element anymore, but we but we see the network as as a single whole entity that can be orchestrated. So, like, create a new services between 2 machines. And then we have firewall rules, routing, route maps, everything that is automated. It's something like the SDN of the whole network, but also systems load balancer, everything. I think that's something that we are doing in the cloud because the cloud is created for automation, but the enterprise network is not like that.

It's anything like that. Unless we embrace a single pillar from 1 vendor and we buy everything from that vendor. And even in that case, we may need to do some system integration between the different systems, but creating our own automation with the small pieces and then having the final goal of a single orchestration between services, it takes time, it takes effort, it needs a very strong strategy to have everything together. And, in the end, we can either choose to become our own software company to create our own system from inventory, from code, from security check, or we can, also, build a system that has some proprietary software, like epifabric, like monitoring, and glue them together. Because automation doesn't mean write a lot of code.

Because most people think automation means we need to write a lot of code. We need 10 people writing code 24 hours per day. This is not automation. Automation is a process. It's more about how we work.

It's just gonna Writing code is part of the automation. An interesting point on this one just comes comes in from the the q and a from Syed. He's mentioned that most most situations in an SDN type environment, each vendor has its own kind of controllers, ways to build and manage the fabric. Is I I guess the question is asking, do you see anything coming up in the market that wouldn't necessarily be driven by any particular vendor that allows users to have flexibility within a multi vendor environment. Do you see something within the network automation practice?

At basic level, it's vendor is try to convince user their own solution is best, and you don't need to to buy their own because you buy 1, and that's okay. In practice, what we see in the industry is more and more, young, I would say, standard model start to appear and start to be more and more well supported across the market. There is some, solution, we can talk about Cisco and ASO, which can do this kind of integration. The issue right now at enterprise level, there is less, difficult time to start user. We see that in the IT world, less than enterprise.

We well, more, I would say, like John Parlow was saying, as orchestrating, I would say, different type of solution, removing API is with product or iPhone, but it's difficult to have a one made solution. And if there was one, that would let's talk about the network automation movement, and let's talk about the solution. Right now, as an industry, we are trying to find, I would say, the right way. We talk about Ansible, which is one of the solution we have. There was TextOn before.

There is some of the WU Network, for example, which provide solution to link APIs, but difficult to have one definitive answer. We've seen a few year. I agree with you, Kazeen. I think the thing here is you would end up with a situation, and we already see this, I think, with some of the models where you you end up with the lowest common denominator sort of effect, don't you? Because because, all of the, all of the things that make give you the reason to to go with a specific vendor or that with a specific feature will only have a certain, only be applicable to certain parts of the network.

And so if you go for that common approach of of having a common configuration model, which I guess is what Saiid's referring to there, you end up losing a lot of the extra functionality you might want around around the, edges. Whereas if you take the orchestration approach that Joao Paulo mentioned, you've got the option of of using the extra features in the different domains in order to to give the the the fullest picture. And I suppose I mean, Orhan, you know, every network is made up of loads of different other networks. Right? And it's all you we're always having to design our way around a lot of these problems, aren't we?

I think you'll need to unmute on. There we go. Let's see if that works. There we go. Now I I can.

Yes. Of course. Networks. Actually, when we say network, it's a collection of other networks, obviously. And we call it, usually, PIN, placing networks.

So campus network, wide network, Internet gateways, IGW sites, and data center networks, so on and so forth, so many of them. And, you may not need from day 1 to automate everywhere every part of your network. Some parts might require more further places. So which you can get the benefit immediately from there. So, quick wins.

Where are those places? Usually, looks like, data centers, but these days, we are seeing almost every part of every place of the network. Yeah. I guess with a data center environment, it's a more more of a bounded problem, isn't it, in the sense that it's well understood. Typically, certainly, a modern data center environment, a very standardized topology, a very, very clear and and, like I say, well understood problem with boundaries.

You get into the campus and and into the one. Right? Yeah. Whole different ballgame. Yeah.

Campus network are totally different. And even for the some customer working with the some vendor, we experienced that we have 10, 15 years of gap between the devices because you can find a very old box from the same vendor, but that may have a missing any API. So you can't you must do anything with an automation with SSH, and you have the latest and greatest account which, that is very beautiful with old API and you can automate. I think to to to to get get a faster result, we we can start, as Horan said, to automate specific tasks and, use the UNIX philosophy. The UNIX philosophy is that you have one command to do one task, and the output of one command can be the input of the other one.

You can pipe. And if you create automation boxes that can pipe into each other, you you can glue them together afterwards, but you know that you can do that. Like, you you have the discovery. So you want to discover the network, you want to collect information, you want to, have this information to be available. And this information must be available in API in a JSON format, for example.

Then you want to create some sort of remediation. Okay. The remediation will use the information that comes from the out from the discovery. Then you want to run, for example, a security check. Okay.

I already have the information about the devices and the software. I can just get this information and do the security check. After the security check, I may have a box that does the software upgrade. So I can pipe out the result. Okay.

We have some box that are vulnerable that needs to be updated. I pipe this information in the upgrading box. So you can have this pipeline of different actions, and then you can add or replace some boxes if you find something better. You start with the Ansible, then you move to, then you can or you can also have the different automation boxes for different kind of devices. Because I can use a Terraform maybe for the data center, because I want to do that automation, and to automate my switches configuration.

But tomorrow, maybe we will have another very cool automation tool. We can just create our own puzzle of different pieces, but we need a very strong strategy because we need to be able to replace and add every, every single piece of our, scenario. And no single vendor usually can do that because, as we said, some vendors focus on the data center automation. Other focus on the Wi Fi automation. It is very hard to find something that can work across technologies, from the data center to the campus to the security.

And when they do that, we rely on them to keep updating it to support all the platforms, to have all the features that we need, and, what happens and when, we miss a feature that is critical for our business. We need to write our own tool anyways. And, again, Paulo, just a side comment about I will say we can swap the technologies. From our side, I will say network automation specialist. Yes.

We can. The main difficulties that we have is beyond that, we have network operation team that you need to cascade, you need to train them. And if we change too much, or if we say, oh, now I want to jump from Ansible to Narnia, you can, I will say, mess? I will say what we want them to do is, like we said earlier on, the process of automation, and they will focus more on the tool and less on the global approach. So it's this is why it's difficult sometimes to say, okay.

You need to have a global strategy. You need to choose your tool. And sometimes, you cannot go immediately for the latest and greatest because you have to take care about the rate of change in your organization and how people are going to add up the solution that you do. I I guess I think We argue for, like, open source versus commercial and that sort of Yeah. Because in in that sense, what you've gotta do is if you go down that open source route, you you end up potentially putting together multiple different tools, constructing an environment, and having to maintain and support that environment, as well as the individual tools that make up your ecosystem.

So it's, but, you know, do you have the same problem with the commercial site? You probably do to an extent. But Yeah. What what it's the maintenance. Right?

Yeah. One note on on that because I experienced that in my team because you have auto the consumers of automation and the creators of automation. Because even with Ansible, you we have some people that who use the playbook, and then we have a a smaller team that creates new playbooks, that creates the new scripts. So even in a big team, usually, not everybody's creating the new automation. They are consumer.

The network operation center consumes the automation that is created by a very specific team that is highly trained because even a Ansible, playbook is not that simple when you start putting some logic inside Ansible, some loops. It's not that easy. It's not that playbook that you can find in an easy tutorial. You need to really get on board. And when when you find the limit of the tool, like, Ansible can go up to a point, but, when you need some very convoluted logic inside the playbook, it it becomes very hard.

So probably, you need to use Ansible, but also Python and understand when you reach the limit of 1, switch it to the to the other. It's clear that an Ansible connection that is ready and easy to consume, it will be the best path, but it is not always responsible. Training is a big part, of course. So I've got an interesting question coming in from from Joppa, who's from Prodacom, one of our partners in Netherlands. And he's saying I think it comes along your theme of of kind of creators and consumers and Julian's theme of needing a a top down strategy.

He sees that automation is a theme. It's a desire. There are some people within structures of enterprises that want to automate certain elements and want to adopt automation, but they struggle to maybe push this across the organization. So how do you how would you guys suggest to engineers that are passionate about automating certain tasks and and capabilities within the network begin to push that change? How do you seek from bottom up to instill, an idea and a strategy of automation in an enterprise that maybe isn't bringing it from top down at the moment?

Julian This is a good question. Even sort of got the first thing, like we said at the beginning, you start with a small use case. We start with the switch provisioning. You start by getting data out of the network. I would say that things like is doing, for example, if, the service team want to know where a server is connected, but you give them a way to know where it's connected.

And then starting from that, you have to know from your organization what does make sense. If your organization is more cloud native, focus on automating AWS. This organization is going to have a new one with a lot of different configuration, and they want to create a lot of virtual network. Start to focus on that. It would be very difficult outside of this to say there is a clear way to automate because more or less, it's really based on use case, based on the organization objectives that you can decide where you want to go.

Yeah. Orhan, I saw you're not in there. I mean, what what do you, hear when you speak to people about this sort of, the the adoption of automation? So, these days, automation, we cannot, I mean, escape from that anymore. So many, even design people, they want to understand high level what's happening in the automation space, to be honest.

So because it's all about money, it's all about costs, cost saving, cost cutting, revenue generation. It's helping to almost everything. So these guys are making lots of use cases. These are real things, which mean we need to get the advantages from that. Why if I can just set up the thousands of site in couple minutes, maybe, why I will spend it was like that, by the way.

Probably, we all gone through that. Like, bring all those equipments to some places then, configure them, ship to the remote locations and all those things takes forget about days, weeks, months. And but now all all of those things, not only consistency, but, reducing the time and effort, all all of them, helping the design process as well. Because in design, one of the considerations is complexity. And when we move the human factor from the equation, yes, maybe we are not completely eliminating the complexity, but we are reducing it, which is good thing.

So we need to get the, advantages from the formation many ways. So think about, like, if if I would give analogy for those traditional people, think about MPLS. You can use MPLS for many different purposes. Think about automation and MPLS. Now let me give you analogy.

You may not use MPLS today for your, VPNs, which is normally most common, use case for the NPS. But you might be getting advantage for from the phase three route on the other side. So, I mean, in case of failure, the time between recovery and the failure can be reduced to 50 milliseconds, let's say. So you can take the advantage from traffic engineering with the VPS. So so many use cases.

Same thing like automation. You don't want configuration management? Okay. Maybe just synchronization of the configuration and consistency. So so many use case.

But which one for you could win? Yeah. And I think I think that's Well, Jus I think I think for me, it's about about having that process and having the operations and and understanding how automation can feed into that process in a in a way that makes sense both in terms of actually delivering it and then in consuming it and making sure that that people are able to consume it in the way that that makes it different to the way they're operating their network. Would benefit from automation, then you swap the manual process out and you put the automated process in, and it allows you to build out that process without changing the way that you deliver the a service. There comes another stage, I suppose, when you've got a certain amount of data and a certain amount of visibility perhaps in in the network depending on your approach that you can then consider.

Well, actually, an automated approach from start to finish would fix a whole load of other things. So you end up engineering new process in order to take advantage of that capability. So it sure. In short, it depends, right, is the answer to it. But I I will come back, Darren, to say a process.

But, yeah, it's a good point of putting process into code, and then you don't leave it to people interpretation. Yeah. And even the fact of putting your architecture or your process into coding will lead to interesting this issue discussion with the guy in charge of the coding because he could have, I would say, implied and for the you are many some, I would say, technical aspect. But in fact, at the end, you say, oh, but you didn't really mean that, and you are actually correct, and the code doesn't lie. I would say can be prone to personal interpretation, but once it's put into code, there is one way of reading it.

And this is also the good that once your process are automated, there is one correct way of doing it. And if you change it, people can use it. Yeah. Yeah. And and and the pipeline approach that Gianpaolo suggested before allows you to assemble that approach, I suppose, in such a way that you can you can swap elements out manual automated different automation approach or whatever.

But still, if it's if it's scripted in that way that that you have it understood end to end, then there's no ambiguity. And I suppose that's the the the point you're making there, Julien. Right? And the question that we can have also is at which point the automation become the weakest weakest weakest link of the network? Because right now, the way we have built up our network, we control plane, data plane, management plane, and we have a sub residency, I would say, and a resiliency in the way our design working.

But at which point, if we rely too much on automation and if we don't have automation, you cannot deploy your new things. The automation start to be a problem in our operation because without the automation, we cannot properly operate. And this is we are the limit to say we are accepting, I would say, more complexity, like, was saying in our design, potentially because we can automate them. But this means that if we lose our capacity to automate, because those tool must be operated still somewhere. But, potentially, we can have an issue at all.

And those are, I would say, very question right now for automation before it was something, like we said, with small use case. So side to the network. And if it breaks, that's okay. It can break 1 or 2 day. It will not I would say, oh, no.

It's a business. Right now, if it breaks, hey. You cannot deploy things that people were taking from granted in one day. So you cannot, I would say, more issue. Actually, there's there's a really good, analogy for that, I suppose, in in you imagine, where where organizations have to fail over to paper processes once if their IT fails.

Right? So imagine a a hospital, for example, if if their IT fails, they end up reverting back almost to to the the historic historical, ways they used to do things with pen and paper. Same kind of thing that you're talking about there. Right? Yeah.

Yeah. But also, how do you, can have any experience on the CLI, for example, if you never deployed that service by hand. Because this is a big big topic, but it is also in the airplane pilot and every other job that is being automated because we made experience deploying switches. So we know how to deploy a switch by hand, how to troubleshoot it by hand. But if you have people that is only using some obstruction layer, they are not aware of the CLI commands of the output other than the GUI, for example.

So I have a blog post, an old one that was something like, are we the last network engineers with the real CLI And I say, okay, but but, you don't know how to operate your car. Maybe my grandfather did because the cars were simple, but today, if you have a car, it's more like a computer. If you have an hybrid car, you cannot really fix that thing. You just calls for support. So I'm not sure that that applies for automatic automation.

I think that CLI is still needed because when seeing things go south, you really need to go under the cover to understand what happens. So, also, the training of the network engineers probably, they need to know how to work with automation, but also how to go type a show command and fix things. I don't know how much, how deep, how much training they will need, but I think it is a great question to Almost everyone everyone will need maybe very high level architects, network designers, exceptional bit of it. Almost everyone learn network automation. Yeah.

Operational landscape is changing, guys. So we have to learn, and it is good investment. So, like, if I will tell you 5 years, 6 years, 7 years ago, learn Cisco I WAN, so I will redirect you to a wrong place. But if I will tell you SD WAN, still correct place. So network automation is not the wrong place.

Spend time, learn as much as standard approaches you can, more is better, more knowledge I mean, but, at least some level that you can automate, you can understand what's happening and then things, happen, troubleshoot at least at this level, you don't have to be so so fair developer. No one says that, but, for that function, there will be other companies. They will do the job like, Iprefabric, etcetera. But, we need to understand what's happening, troubleshooting, and maybe sometimes, if necessary, small code we will run. But of course, it is your choice.

When, I think Paolo was talking about Ansible versus Python, when it is I mean, when Ansible cannot do something or you need to write the modules and all those things. I thought maybe, a tool. Yes. These are all tools. Whichever is coming in, of course, you, you will choose that one.

Probably, you might say, like, VRF lite for the Ansible, the MPLS for the Python. So scalability task like I am talking about. Whichever you choose, whichever is easier for you, you need to learn. You will understand that. Let's not make it Start today.

Whenever you have time, have a look at some basic stuff. Some certification even might be helpful for that aspect. Maybe put, certification is good for giving you a way hierarchy to, study something. That's why. Otherwise, I don't need to say any certificate now.

We are not making a requirement for anything, but, this is the point. Mhmm. So a question question coming in here. I think just to to recap on the points that we've we've touched on, architectural strategy should be led by an integratable and intermixable pipeline of quick wins. So we've we've kind of covered this.

Orhan's mentioning that training is critical. Getting a balance of automation, Gianpaolo mentioning still being able to dive into the CLI when it's needed. So looking a little bit more into the apps actual, kind of adoption, the actual adoption within an enterprise and in this question's sake, it says within the Dutch government agencies, there's a lack of change management. Doesn't matter so much because maybe the number of changes are relatively limited and the slow manual processes are quite trackable. It's it's less of a a rapid change.

So if in the government, they're they're following this kind of complete evolution towards automated processes and all of these different tools, different skills being adopted, yet those change management processes are not there from the start. How do you guys approach from an automated standpoint? You know, which which approaches do you have to make sure the processes are in place, that there are fallbacks, there is change management tracking throughout the early adoption? I've read the Darrin question, and, yeah, the question was how can epifabric, I would say, help about that. The big point was, Darren was mentioning, is the negative application, I would say, for the process.

For me, the first point, it means that what are the negative application? What are the important point for your network? Are you interested to go to this application? Are you interested to go to the SaaS application? Does that what does your network is providing really for?

Once you have that, if you take the example, it was specific specifically for IP fabric, you can generate pass in IP fabric and to know to monitor them. And then you have the snapshot every hours, every 2 hours depending on the size of the network. And you check check if there is change. And you've I noticed a change, like, if I can do help you to do diff of configuration, and then you can check, I would say, what was the change occurring, I would say the high level pass. This is, I would say, you observe the result.

If you want to go forward, you we started to talk about Internet based networking. It means that you need to model your network. You need to start to use tool like bad fish to really model what you want to do, ask question, but then you start to be very, I would say, deep in automation. It's not a quick win. I would say you start to to add the next step, and it's not something you can do and stuff from that.

And I just yeah. Go on. I was just gonna say, I mean, intent based networking, now you're talking you're you're getting into futures. Right? Because really what what you're you're trying to build here is this this idea of a of an ecosystem of of elements that work together almost to provide an autonomy in the way that the the network is behaving.

Right? Because you define your your intent in a certain way, in your essentially, your source of truth. Yeah. You have a fulfillment element that goes ahead and actually carries out the automation. So it builds elements of the orchestration that Gianpaolo mentioned.

All of those things about about, the the the pipeline of of of automation in order to to fulfill that that intent. And then you have reassurance element, which is where IP fabric comes in in this case, which allows you to to visualize and understand how the network is actually behaving and compare that with the intended source of truth. Right? And then provide that feedback loop to to build Let let me share something Please. Perhaps to explain Yeah.

What I'm talking about. Yeah. Is it okay? Do you see it? Yeah.

Yeah. Yeah. We got it. Because for me, what we said is, the super truth, this is a model is where we want, I would say, to model our network. This is where we decide and like Ron was saying, this is a design part.

This is where the architect and the designer will say, hey. Isn't it what should look like that? Where we store it? It can be dead box. It can be another source of truth.

It can be whatever you want, but there should be one place where you say, this is how I want my network to look like. Then we can have automation tool. We started to talk about the pipeline, started to talk about Ansible, Python, whatsoever. We can have a way. We can have tools, Terraform and so on to modify the system.

The system can be the network, can be the cloud networking, can be whatever we want. And what we do look, we need afterward, this is a feedback loop. Too often is an automation process that we can see in some blog. There is a direct pass, but there is nothing that could. In fact, in real life, people are going to make change on system directly.

Like we said, whether we like it or not can be because there is no change process in the organization because there is a crisis and you need to modify and fix something quickly because like we said, we need to sometimes jump on the CLI and fix fixing things. And this is where we use IP Fabric. I would say, like a state database system of records if we tap all name, I would say, to help reconcile between the system and the source of truth and you start to have report within whatsoever you want to compare what you have, what you would like, and what should be. So this is, I would say not you cannot have one system. You need to have 2 different tools because of severing different objectives.

Yeah. Because you want checks and balances, don't you? You don't you don't want people to be marking their own homework. So you have to have that that ability to separate out those elements. And then they work in concert, but, but but towards that same goal.

Yeah. So Yeah. So example I give to people usually in the team is if a switch is done for a technical problem, it's out of Happy Fabry. You don't have it. Because in this current snapshot, Hyper fabric is done using it.

It's not present anymore. You don't have the information. Still, in your super truth, this switch should be present. Because it's still an operation, and you need it for long term. This is why you have 2 different system because that's a ring different world.

There's no question at the moment, guys. But just on that on that point, I think the the thing that we hear very regularly is about the source of truth, and it's usually being spoken about the loudest within the automation community. If this is if we're talking early adoption of automation, would you say the source of intended truth is a first priority above the source of observed truth? What do we actually have now, or do you believe they both need to be developed and deployed in parallel? Shall I I'll take that one first because, it's a a question that that I get similarly.

I think I think from a from an automation standpoint, the the key part, if you're if you're wanting to push out on along that automation path is to have that intended source of truth first in order to give you the parameters and the boundaries within which you deploy your automation. You know, there's there's no question. Without without without that, you've got no central source of information to actually push, that data into templates, into into policies that you can deploy in your network. The difference if you really want to make the the difference as a whole though and and understand that that is actually delivering what you expect it to, then you need the checks and balances. And that's where that observed source of truth, the system of record that that that that Julien mentioned before or the assurance engine in the intent based networking scenario.

That's what that that's achieving. So there's there's an important difference between that intended source of truth and that that, observed source of truth. But if you want to do the whole thing and get the whole thing, as autonomous as possible, then you have to have both. Julian, you were itching to to Yeah. Yeah.

Yeah. It's, if to answer the question, I will say, if you start with the greenfield network, you have a new use case, yeah, go with the intended source of truth. If you start with the brand feed, you arrive with a new equivalent, you have a new perimeter, no stuff with the wholesale. So it's a true stuff to use it similar to, like, epifabric, but discover and try to make sense of the next. Because you cannot create a model, create an intent if you don't understand how it's built.

So you need to have at least this visibility before starting moving to the model intent and then potentially automate. Like I said, is when you want to automate on a network, first, you must simplify it. You must analyze it, use it, model it to be able to orchestrate it. You cannot you cannot go directly to the end. You must do your step, and you cannot automate if the design at the end is a mess and you have, I don't know, 20 different, design in each companies that you have.

It would be really difficult to automate. I will not know the deployment if every time you have a specific if loop in your if in your Ansible playbook to manage this specific use case, you must standardize before the meeting. This is really important. It's not because you cannot automate so that you don't have to do any more network design or organization. This is a key element.

If you want to automate, you need to talk about. Yeah. And and not only for automation. I'm working on an SD WAN project right now that has some automation in it, but we are redesigning the routing of whole the sites, data center, and branch sites. And we are finding years years of layers of different tuning tweaks made with the different style by different network engineers that were there over time.

So, we are cleaning up a mess that is very, very complex. I agree with you, Julian, that the the automation project can be a good chance to find and remove thousand of lines of configuration that are not not needed anymore, or even if they are needed, they are too complex to be maintained. So if it is very hard, if you cannot write a clean piece of code that can generate that configuration, ask yourself a question. Do you really need that configuration? Do you really need all the tweaks, all the exception to that, or should you rethink the design?

And probably, there is a better way to do to do that because there is a joke that the CCIEs really like to tweak every single parameter of every single routing protocol that you that you can. So with BGP, it's like paradise because you can mess and play a lot with it. But when you do the automation, you you need to to to have a template to generate that. It is a very good time to rethink about the design. And, I think this is very important because sometimes defaults are based on the complexity because either something very complex breaks and nobody can really fix it or nobody can understand it.

And if if you are doing automation, need to understand what you are doing, and, you are forced to do that. And you write the algorithm that will generate that configuration. I think that is a very big plus for, for network automation. Yeah. I think I think that complexity piece, is is really important, isn't it?

That that we you know, it's unavoidable, really. The networks that we work with today are so much more complex than than than they would have been even 5 years ago, 10 years ago for sure. When you look at all the layers, when you look at all the interactions, I suppose, between between all the different elements, And so I guess, yeah, the automation allows us the the two parts of that to to go ahead and and analyze what's what's there in the brownfield as Junie mentioned before to to understand what it is that you've got so that you can know and understand the environment that you're you're using, but then in order to deliver anything new, you deliver in a consistent and and way that's that's well understood and well engineered and so you've got that that ability to make sure that that those two elements are are looked after. That's a good point. So an interesting question.

I hope I'll I'll get it right to to spark the conversation. But if the source of truth is fed by a tool like IP Fabric or a similar similar tool, which represents the running infrastructure, what's the difference with a traditional CMDB? There is a further further element to the question. Shouldn't there be a separation between source of truth and IP fabric even if it's not looking at intent based compliance. So I think the point you mentioned, Julian, is that the systems do absolutely need to be separate, the intended source of truth and the the running, infrastructure visibility.

How would this this differentiate from a traditional CMDB? No. First, the traditional CMDB didn't have the data model that we have today and the different sources. The inventory, the CMDB in the past were mainly inventory, some network information, and that's it. You will not have VRF.

You will not have ASN. You will not have the link between the villain and then the villain group and whatsoever, depending where you are. You have much more complex model now that fits and where you can really represent what is your intent in term of networking design. But the concept that you use to manipulate as a network architect or designer, you can already put it in a place. Before CMDB, you cannot represent the logic of the network.

You can represent the plumbing, the name between the switches, if you want, but that's it. The 20,000,000 dB were really limited to that. Things are changing. ServiceNow, for example, is a little bit evolted. Nonetheless, ServiceNow, you cannot model, I would say, perhaps 20% of what you can do inside inbox to have compared release of both of them.

So that's why traditional CMDB is matching. The CMDB is the lowest command denominator be denominator between all the teams that took already. Because, potentially, the seller team, we need more things and so on. So you have central things, but the smallest things is okay that you can do quite well. Yeah.

This is similar to what we were saying before about the lowest common denominator Yeah. Levels. Right? The the CMDB was there to serve a particular purpose. That purpose included things like making sure you got support contracts and making sure that that you you're, you understood power requirements and and those sorts of things, which which were were very very flat in terms of the data that they needed.

There wasn't the understanding and the requirement for for building the relationships and the modeling of the of the the topology, if you like. But we we need the CMDB. It's just that for me, the network source of truth should feed the CMDB. And the network's source of truth, it becomes, I would say, the master information regarding network, and he's feeding the CMDB so other people can come and consider this information. It's not I will say we're not opposed them, Zao.

You need an enterprise CMDB. You need a place where you have everything in one place, but just that sometimes you need a dedicated tool more powerful for your need. Yeah. No. Completely that.

And and that's and that's where we're getting to, I suppose, is this idea of having that single source of data that disseminates out through the network so that you you know that your data is always consistent regardless of which tool that you're accessing that data from. Right? So so if you have your source of truth, then then, and that is is let's say let's say, for example, you have your NetBox source of truth. You have IP fabric there, busy, assuring that the source of truth is accurate and and correct based on what's actually in the network, then you use that as a source of information to feed out to your monitoring platforms and to your your, ITSM to make sure that when you're raising tickets, that you're raised against devices that exist and where that they're in the right place and connected to the right things. And that those relationships are maintained in your source of truth, but then fed out to all of those other elements.

So allowing you to use that same data for all manner of different elements. So your security teams, your operational teams don't have to go begging to to the network team in order to get this information because the platforms and the systems themselves disseminate that information out. And that that feeds to to the data democratization thing we were mentioning, right at the beginning, doesn't it? Because you've got that data. You want to use it as widely as possible and make sure that everything is consistent as possible across your operations.

Yeah. So do we think coming into I did the two points that are flying around, data democratization and one of the points we wanted to require like, question is, what do you think some of the more advanced use cases could be if we've translated the network into an accessible, queryable database and there is this data democratization in practice, which I guess also feeds into future trends. Do you see some real advanced use cases from this deployment of an automated, somewhat intent based network where this data can be used by other teams now without having to feed through traditional communication routes to slowly get information from the network team. You've asked the question there. Look at the concentration.

I'll dive in first. Shall I? The the I heard it said, and I've heard it a couple of times in in recent weeks that network data is considered like oil, like like gold. It's it's so valuable in order to educate all of the operational processes from across IT, Because because everything is built on the network. The network is fundamental to to every single other IT process.

So for me, having that integratable, ecosystem, using an intent based network to to, maintain and and and have the this this auto autonomy, if you like, of the environment, then be able to extract the data out in such a way that it can feed other processes has got to be the way forward. What that ends up with is is 2 things in my head. The network engineer is still the network engineer because they still need to understand how the packets flow, and they still need to understand how that network, it can be troubleshooted if it's shot or shot if there were a problem. But they were also a data scientist, and this this is where the parallel comes with with other other folk who use Python because Python has become as much as it's a programming language, it's become a tool for data scientists to actually dig into data, you know, in the vast volumes that we have of it now and really make sense of it and understand it. And because if you model the data appropriately, you can use those tools to really get to the to the depths of what that data can do and what it can mean.

So, yeah, I mean, that's one of the things that that I bandy about a lot is this idea of of a of a network engineer as a data scientist and why why you need to learn to program as a network engineer, not necessarily just to be able to go change config on loads of devices. But but Julian's gonna ask Yeah. Let me just let's go back to a question that was in the chat, not in the q and a. Someone say how Steve is saying how you can cope, I would say, with all this new technology as a young network engineer. And he's right because I would say when you start, and you're right now in the market, there is a lot of, I would say, traditional information, but there is a lot of new information and can be very, I would say, difficult for a young engineer.

But I would say you start somewhere. You start at least I think for me, the key element today is Python, at least a programming language, let's say. Let's say it's only Python. You can just go if you want, but you need to know how to program because like we said earlier on, you need the ability to get to API, get to data. And this is not only, I would say, limited to CLI.

It's funny because I have, I would say some, sales engineers or brilliant guy who told me, who are still in the market, but told me, I went into networking because I didn't want to do programming. And now it got back to me, and I need to learn programming together to do better networking. So we have the I would say it's TensorFlow. And even so, even before, we are not really programming, but you can still do TCL script. Even before doing a little Python, you can do still basic programming.

So to come back on the complexity, you start little by little. I would say you you run on the Internet. You try to make sense of it. All I was saying is the good part was the certification because when you do a certification, it's been people from which are more expensive than you, had drawn you a path of what you should learn to be able to get a sense of all of it. So this is where when you start, certification are important because they give you a great way to estimate information.

Afterward, hey. You're all by your phone. You need to learn. You need to be, I will say, curious and check by, by yourself. Right.

I mean, the the curiosity thing, of course, is is is natural for all network engineers. Is it not? That is not just what we are. I I just just just an observation. But, Gianpaolo, what do you think?

Yeah. I I'm. Discussion, early on about the network automation. How much code do a network engineer needs to write? I think you need to learn, and, you should be able to write a little bit of code to poll the network about information, to generate configuration, to validate some key points like running tests.

The next layer about building a whole orchestrator, I think no network engineer will ever do that, or will ever be expected to do that. I can't do that. Coding is hard because, I write a lot of, common live scripts for my work. So, like, just a few line of Python, click. I have my own command.

I can just pull or do massive change on the network, and I just beat some small commands that are really useful for me. Also, when I need to design a network, a new piece of network, I can pull all the information, but I can't say I write code. I write scripts that are very useful, have a very big impact on my work, but are not actual code. I see code as a very big, like, data modeling. How much time do you need to spend when you're writing code about how to model your network, about all the validation of the input, how to check about all the exceptions.

Then if you have software, you need to maintain software versioning. You need to verify that it's, secure, that you are not, publishing passwords or the access. So it is very hard to write code. But a hybrid team may arise then because you may have the experience in network engineer that works with the people writing code that study probably a little bit of networking again. So you can have a mix of people that can create a team that can get a result, but I don't think we should expect, like, the network engineer that is a CCIE and senior Python programmer.

They they there are a few. I know personally that there are a few that are really geniuses, but we should not compare to them because really it's a too an expectation that is too high for us. So learn to code, but don't feel that if you are not building your own libraries or your own orchestrator, you are you are behind the curve. We are everybody. We are there.

We are we are learning, and, probably, you cannot do a career in networking today if you are not learning coding. But, yeah, it would there is a limit of what one person can do. I would just want one thing. Writing code is easy. Making code is harder.

Yes. That's This is more disappointing because yeah. Orhan, are you gonna be, learning to be a software developer then or, you know, on top of all of your your many skills? Of course not. But, as I said, a little bit of coding and this is must for all of us.

And, if today fresh graduates, let's say computer engineer, what they should do, if if you are considering to become a network engineer, 2 things I think they should learn, they should understand from the very first day, design mindset, network design mindset, and network automation basics. For design mindset, please have a look at for the free videos also my YouTube channel or on our YouTube channel. Also, one video I did with Darren there, I think, video 4, something like that. You will see the title with the network, design architecture talk with etcetera. If we look at those 4 videos, 6 hours almost for entry level to the design, let's say.

And then automation, there are many also videos out there. If you look at IP fabric website as well for that. And, so those two things is important. Fundamentals. And then you go there.

From there, maybe, different tools. Even on the design, you can have, of course, advanced knowledge. On the automation, you can have advanced knowledge. Where you will go from there, you will decide, but But fundamentals must for us. I think I think the key thing really is just keep learning.

Right? I mean, as far as as network engineers are concerned, you can't learn too much and and make it as broad as you possibly can. So, yeah, I think that's all good. And it's our job that we say as well to spread the knowledge inside our team to help our team to learn, to learn how to code, to learn how to use. And, yes, this is more It's not only doing by phone, it's sharing it with the community or sharing it with your team.

I was gonna just say, actually, the community element of all of this is huge. Right? Because between I mean, hey. Without it, we wouldn't have met as as a group, but also, you know, there there is so much knowledge out there that people want to share, you know, and and what a great source of of information and inspiration as well. Yeah.

I'd say the we're speaking obviously with customers from all different countries, cultures, backgrounds, states of network evolution, and we see the same requests, the same types of projects coming up over and over again. How do I begin with these elements of automation? Could I look at my source of truth? This is how we're looking to do it. Do you have guidance?

And we steer people to the community because there's already people delivering these type of things and very much in the, in the essence of sharing. So, Darren, how would you suggest people check out the community, get involved, keep an open ear? Well, you could do worse than following the the the folks on here, of course, because, you know, there there's a lot of community involvement just in the, in the faces you see in front of you here. But, you know, and and Twitter and and LinkedIn are always always good places. We, obviously have our own, IP Fabric as a Slack channel, and, we're just setting up a Discord group, in order to to sort of communicate directly to to our community.

But, you know, there there are so many options. The best thing is just the link with with the people you see in front of you, I think. Perfect. Thanks, guys. You also, you guys please follow on your LinkedIn as well.

Mostly, I am using that. And where would I tag Dash? You can you can follow that. Usually, these these folks anyway, yes. But there are, some other people also which, continuously I am sharing some of their, efforts actually in the automation as well as design, network design field.

Perfect. Okay. So we'll we'll probably close off the discussion there. There will be another Ask Community fabric webinar coming up probably around May, which is, I guess, the the sneak peek. Well, there's no sneak peek for the audience today, but the the panelists are probably looking more on the software development side and scripting side to the network automation story.

So something for you to keep your eyes peeled for there. Final thanks to to Julian, Jambala, O'Han, and, of course, Darren for your for your time this afternoon. And thanks to everyone who's joined. Thanks for the questions. We will be sharing the recording out and, really look forward to any more questions.

Feel free to follow all the guys here on Twitter, on LinkedIn, and ask away and get involved in the community. Thank you, Joe. Thank you. Thank you very much, guys. Have a great afternoon.

Bye. Bye.