Nokia Event-Driven Automation (EDA) Multi Vendor – Deliver on the Promise

So my name is Bruce Wallace and I run product management for Nokia's EA product, the platform we're gonna see today deliver some, uh, AI capabilities. Now, I hope you all have your bingo cards for the number of AI words we're gonna say, and I hope you've been counting the number of times that, uh, AI has been mentioned already. Um, I'm sure the people on the live stream will keep a running count for us.

So yeah, first before we dive into some of the AI stuff, uh, I set on not this stage, but a room like it, uh, about a year ago when we unveiled event driven automation, our new automation product for data centers. And we made, uh, some broad statements. We talked about, um, Kubernetes a little bit, much to the chagrin of a bunch of networking people, I'm sure.

I promise this will be a very, very loosely part of this presentation. But we talked about Kubernetes as a platform, uh, for automating workloads and now how it had become basically the ubiquitous platform for automating workloads. And we talked about why it was able to do that.

Obviously Google has a a lot to say for why it was able to do that. But our two kind of assertions were that the things that did really, really well was it brought the concepts of abstraction to infrastructure. As in kind of what you see here.

A pod always looks like a pod no matter where it runs, no matter the underlying Kubernetes distro, no matter if that pod is running in public cloud, if it's running on-prem. This idea of building kind of an abstract model to define the unit of work that we want to automate. The other thing we talked about is using the concept of being declarative.

And what we mean there is the idea of I can take a, uh, you can imagine the old days of SNMP and SNMP sets where you had to roll in a network instance or some kind of IP ver before you could attach interfaces to it. There was a sequence of steps that you as a human had to kind of undertake. And really we wanna move that to the underlying platform.

So we wanna say, I want you to get from point A to point B, but I don't wanna tell you how to get from point A to point b. Kubernetes does this through something called a reconciliation loop. Again, not super relevant here, but these are kind of the two assertions we made.

It's declarative abstract. This is why it has been super successful. And obviously it's had, you know, Google as the massive monolith pushing it, uh, both for their internal use, but also open sourcing it and making it available to the broader community.

So when we started ada, we really wanted to think of some of our networking primitives through that same lens. We think of network instances and interfaces and les and all these types of things. We really wanted to try and build a model for normalizing these, no matter the underlying operating system, no matter the underlying version.

That was kind of our, our big claim. Uh, a year ago we showed two operating systems, uh, under management of edda. We showed SRO Linux being our operating system for the data center.

And we showed SRS being our operating system for the wide area network. So to deliver on some of that multi-vendor promise that we made, we wanted to show you how we've kind of improved on that over the last year, uh, and show us talking to some other vendors. But we also made another claim and, uh, this was more controversial than I was kind of hoping, um, was first we liked the idea of abstractions lending themselves on top of other abstractions.

We call this kind of like composite intense, if you want to use that term. But the idea is there really should only be one guy that configures BGP peers. And if someone else wants to configure a BGP peer, you use the guy that knows how to configure BGP peers, right?

The code once, leverage it a bunch of times. And we also made the claim of we wanted to bubble state up through these same automations. And uh, I remember, uh, we had a guy from Steam or Valve, uh, that pretty much didn't like this, liked the idea of having a separate platform for automation and another platform for kind of operations and dealing with alarms and stuff.

We like to the idea of we have a a fabric, it's a nice abstraction for how to build the underlay and all the inter switch links, how to address them, why not bubble up some state into that same project that you as someone working in operations, can view your network through those same abstractions and can operate your network through those same abstractions. So ideally, if my demos work today, we're going to see some of this, I will, uh, sit down. Getting over will hurt me.

So to start with, I've got a pretty simple topology here sitting in eda, uh, four spines and four leafs. Lemme see if I can make that smaller go. And I'm not gonna call out which is which yet in terms of operating systems.

But what we want to do first is this is just a topology that's been spun up. You can see we have some links between everything. This is leveraging ADA's digital twin.

We're not gonna harp on the digital twin too much today, but for those who, uh, didn't see last year's sessions, the idea here was we wanted to be able to simulate basically everything we're talking to so that as you're rolling changes into your production network, you can simulate them first. Roll the changes in here first and assuming things pass your changes, uh, succeed and you get the result you're looking for. And automated process for rolling this into production.

So we're just using this as a bit of a playground here. There's no real hardware in play here. And right now all I have is topology.

There's basically no configuration sitting here. So the first thing I'm gonna do is build one of our fabrics. So if I grab some config here and I'll walk, 'cause this commit is gonna take a second Coming an upgrade from note notepad plus plus, right?

A mu much big upgrade. Uh, we're going to add fabric here and I'll commit this. Okay, so I'll talk through what I'm doing here.

It's gonna be going in the background. So this is a fairly complex fabric. Now you'll notice that we're bootstrapping a topology of eight nodes with a bunch of interest switch links.

And I'm doing this with 58 lines of yaml. So when I say complex, it's complex in the sense that we're returning on BFD, we're using BTP for overlay and really adjusting timers here. I tried to exercise as many of the knobs as we support in our fabric resource, our fabric abstraction as I could so that we could see how they play out the devices themselves.

You'll also see that, uh, we're selecting things to deploy to based on this concept of leafs and spines and leveraging labels. So you'll see this as a pretty common theme throughout a bunch of the demos today. Uh, this idea of indirection.

So we want things to kind of reconcile based on labels being applied to different things. I'd already gone through in my topology and labeled my leafs with a leaf roll and my spines with a spine roll and my super spines with a SuperSPIN roll, although there's actually no super spines in this topology. You can see we're using, uh, IPV four and IPV six.

So this is a, a dual stack fabric as well. And hopefully I from over here, our commit has been successful. So I'll jump into the details of the commit here.

So you can see that, that, uh, that slide, I hit it before. In fact, I'll flash it up again. This idea of like, all I gave to the system was this fabric resource, this purple box, and it's gone and created all these other boxes, which are just other abstractions that it's leveraging.

And in turn, we ended up running 165 intents, kind of little chunks of code that deal with automation. We outputted 610 new resources. We don't need to go through all of these.

Uh, but the thing is, we did a bunch of work just by giving the system a very, very simple input. And if I now come and look at my diffs here, I'll jump into one of these leafs and maybe make this a little bit easier to read for you. Does anyone recognize this configuration?

I'm hoping there's a delegate here that might be familiar with Nokia products. I'll give you, i I gave you the coin flip. It's either SR Linux or SRS.

Does anyone want to take a stab? No. Okay, so that's SR.

Linux, it's configuration for Linx. You can see we're getting a nice diff view. This is the configuration that was actually pushed down to the device.

A bunch of configuration was pushed down to the device, including addressing V six, turning on RA sitting preferences for, uh, for protocols, a bunch of configs that I didn't have to figure out and, uh, and push down. If I look at Leaf two, this is, uh, another Nokia product and there's only one left. So you can probably guess this is SRS very different configuration from from Leaf one.

And again, I wasn't privy to uh, to what config was pushed here. I didn't have to to tell anything special other than you're talking to an SRS node, figure out the correct config to push also a config here. This is maybe where it gets more interesting.

This is, uh, not the prettiest of data models, but does anyone want to take a stab as to what operating system this might be? And what is worse is this does look different from the CLI of this operating system. So that's a bit of a hint.

It's an operating system that doesn't have kind of a line schema for their model driven management and their CLI, anyone. So that's Cisco Nexus. And then lastly, if I look at Leaf four, I'm hesitant to ask, the delegates here aren't super active, but that is, uh, that's a Juniper one unos.

Uh, you're close. It looks like open config, which is why you jumped there. Oh, that is Arista.

Yes. Very good. So we have four leafs, all of different operating systems.

We actually have four spines, all of same, uh, all of, you know, sequential operating systems as well. And we're configuring that using that clean abstraction. So we made a promise a year ago that we would support multi-vendor.

We're kind of delivering on that promise today. Uh, if I go back and look at my fabric just to highlight something else, you'll notice that we're getting that abstract state as well. So, uh, we have the concept of health in eda.

This is like a composite of all those underlying resources and whether or not they're healthy, bubbling that up into kind of this abstract resource. If like a BG PP were to go down, for example, this health would change and the fabric as a whole is operationally up. So this is kind of bringing in that concept of state as well.

So we're checking using telemetry, all the BGP peers, all the inter switch links, uh, everything that we configured. Uh, but they say you don't need to do all that. We, uh, give you the nice abstraction to view it all through.

So the next thing I will show is quick Question, Bruce. Yeah, uh, Ethan, um, how difficult is it to add a new operating system to your abstraction? Oh, that's a great question.

Um, I can give you estimates for how long it took us to add the two that we added being Nexus and EOS. I would say it was roughly a couple of months, uh, for coverage across the board. Like we have a lot of resources in here.

We support the vast majority of them with, uh, the two operating systems. We've already designed all of the intents with this idea that they have kind of the pluggable operating system layer underneath them. So getting full coverage, um, I would say on the order of probably three to four months, we're not quite there just yet.

Um, but getting the basics where we configure the underlay IP addressing, you know, bring up BGP, all those types of things very, very quickly. Mm-hmm. I would say on the order of, you know, one to two months, A question for you as well.

Mm-hmm. Uh, Rita Younger, um, you started with yaml mm-hmm. Which is kind of a concern of mine because you know, in the customers I work with, not a lot know Yam L.

Yep. So do you have any options that do not include having to know some sort of automation or programmability? Yeah, for sure.

The only reason I'm using YAML here is purely because if you saw me go through and enter everything into the form, my demos would take longer. And I have a lot of demo content to get through. But if we look at that, uh, that fabric resource here, I've already got it open.

Actually, what I could have done instead of filling out this, uh, this yaml, in fact I can hide that, is we have this nice form for you to fill out where you can just set things as you like them and then you get auto completion, all that type of thing. So yeah, you don't have to be exposed to the yaml. Um, I'm just using that purely for demonstration purposes to make it faster to configure things, especially considering I was setting so many different knobs just to show that we can set so many different knobs.

So yeah, you don't need to be exposed to it if you don't want to see it for sure. We also support JS Om, but I assume your answer to that would also be the same. So yeah, we have a bunch of different ways to view the resources through different interfaces.

And are these controller based systems, Uh, Have an appliance OnPrem? Ah, good question. So we will show our SaaS platform a little bit later in one of the demonstrations in the afternoon.

This like as a product is just a bunch of processes that run on top of Kubernetes. So you can onboard this onto your own Kubernetes cluster if you like. We do have, uh, kind of like our, our tailor made installations using like embedded Kubernetes distros and stuff.

So in terms of deploying this, you kind of have the whole spectrum. You can go from appliance kind of sold by us through to, I want to bring the Kubernetes cluster and I'll just onboard you as an application on top of it through to SaaS if you don't want to deal with any of that. We, uh, have every deployment model under the sun at this point, including VMs and all that type of thing.

And, and if I, if I could pile onto that. Sure. Yeah, yeah.

Um, Steve, the, um, the four nodes that you entered here, how much of the, the logic between leaf and spine and the specific interconnects is automatic with this tool and how much is, has to be known by the person filling out the form or creating? Uh, almost a hundred percent is confused by the tool. So the only thing you need to do is we have kind of topology designers that even let you spit out that exact pathology and we'll do all the labeling for you.

You can obviously tweak that labeling if you like, like you could label your leaks with some other label if you like. So the only thing you need to know is I want to roll this out across this set of nodes. And those nodes have this label, so all you're doing is selecting nodes to include.

Um, and you would've seen, I have this interest switch link selector as well, which is the links between, and again, our topology builder did this all for you. They're also labeled all of the links between, but in terms of figuring out what the topology should look like, I did that up front obviously because, uh, some of the other vendors take a very long time to spin up their simulators. So I wanted to make sure I did that ahead of time.

Um, but everything else is kind of covered for you through our topology designer. And then the only inputs you're giving are I want to select these things just based on those labels that were predefined as part of the topology. Okay.

So it can be as simple as I'm gonna tell you these four nodes are the spines and these four are the leaf. Exactly. And this, the script is gonna be able to, It will figure, it Generate all the, all the other detail here.

Yep. Yep. And if I don't know how to write the aml, I just have to tediously fill in the form.

Exactly. Which, yeah, that's why I didn't do it. No one likes to fill out Forbes.

Um, so I'll show a couple, couple more things here. So I'm just gonna jump to our queries and I, again, I showed this a year ago. Everything you kind of see in ER is live streamed from the devices.

So we are very, very heavy on GMI and GRPC in general. Um, but we don't store a lot of state, uh, a lot of state ourselves. We do have the ability for, uh, these kind of abstractions to obviously subscribe to low level state coming from devices so that it can figure out operational state, that type of thing.

But we also allow you to kind of go in and query things yourself. So I'm just gonna run a few different queries here. You can see, for example, this is querying every interface on every ESTRO Linux device in that topology, of which there was only two, there was my leaf one in my spine one.

Um, we can do something equivalent. And actually just to save me, uh, typing this out, I'll copy and paste here. We can do the same thing for our estro s operating system.

And so when I'm hitting enter here, it's actually reaching out live into the network, and now it's starting to stream the results back. So if any of the fields were to change, let's say an interface went from like opera up to opera down, you would see the fields live change here, kind of, there's now an ongoing subscription to this path. Uh, we can do obviously the same for EOS.

So this is showing us interfaces in the topology, the four and spine four. And, uh, nexus, who I'm not ashamed to say, has quite an ugly data model. Uh, the same thing.

So we're now live streaming this. So we have like all of the state plugged in for all the different vendors. We have all the abstractions plugged in, both on the config side and uh, uh, on the state side.

So it's kind of like fully functional here. Again, that's, that's telemetry coming in from the boxes that you're reacting to. You're not polling.

Exactly. Yeah, yeah, yeah. We're using on change subscriptions, so we're getting everything coming live.

Yeah. Okay. So I'll do kind of, uh, the next part of our little demonstration here, which is to build, uh, some overlays on top of this.

And I'll do the same thing I just did and copy and paste some yaml. Sorry, Rita. Um, now this, again, I've tried to exercise as much of our virtual network capability.

This is kind of our concept of an overlay, an EVPN overlay. Um, I've got four different VLANs. One will go to each one of my leafs.

In fact, before I talk through this, I may as well, uh, this. So I'm not gonna go through and do some of the dry run revert stuff that we showed last year. We're trying to, to highlight multi-vendor and AI capabilities today.

But you'll remember those that either watched the event last year or they're in person. We do have the ability to dry run. We're holding onto all the schema for all of the underlying devices we're managing.

That's how we interact with them. So you can test these changes, obviously without pushing anything to the devices to make sure they work. Um, and our backend is git, so you can actually kind of revision control all of this in gi.

You can jump around based on that revision controlling as well. And we'll see here that our virtual network has been deployed. I'll do some of the same thing just to show that we are actually configuring stuff on these devices.

So on my Leafs, now you'll notice the spines didn't get touched at all. We have some sub-interfaces, an IRB interface with some addressing. Same for SRS who calls these VP Ls instead.

Uh, same for, I think this is Nexus. Yes, that configuration's very, that's our Nexus configuration. And then we have EOS, so both underlay and overlay covered along with all the routing policies, all the other kind of bits and pieces that you need to make this all work.

And this was across a fairly complex virtual network with, you know, four different VLANs, four different, uh, IRBs all attached to a single router with BGP turned on. I tried to exercise as many of our knobs as I as I could here. So that's kind of the first part of, uh, of our demonstration here, showing multi-vendor and showing that we, uh, have delivered what we promised to deliver on.