Make Intent Verifiable: Nokia IT’s New DC Fabric with Nokia SR Linux & Event-Driven Automation

That complexity takes us to, okay. You've got some great ideas about where you want to take the network. Um, you made some decisions about some products.

What did you, what did you select going forward, and what did, what did this do for you in light of the requirements that you all saw? Okay, so, so our requirements was to have a modern design implementation operation cycle, you know? Mm-hmm.

So we, we need, we use NetOps techniques mm-hmm. Where we, where we're treating our network as code, right. And, and when treating the network really as code, um, I mean network as code, the, the concept itself has been there for a long while.

Sure. But it's been always, like somebody will tell you, write your network as code, and let me write a translator in the middle to enable this network as code to be understood by, by, by my tool. And then, and then you have the tool understanding this network as code, but it never tells you if it's really implemented your, your code or not.

Sure. It says it's accepted. So we had this idea of that our network, uh, our network as code should, if it's really network as code, then let's treat it as really code, let's treat it and, and put it through a software development cycle.

Mm-hmm. Like we're, we're gonna be more like software engineers treating our network, uh, as really software where we have a production environment. We're, we're taking, we're we're putting it through a virgining system like Git, uh, taking branches, uh, implementing changes in the branch, testing them, feeding back into, into production.

So really this was our vision to have, you know, a NetOps a, a process or, or, or architecture that treats network as code. But we really wanted to, to have a tool, a tool that really understands the code by as code mm-hmm. And not translate it onto something else.

Sure. Why we wanted to feed, we wanted the tool to feed us back information about our real code. Our real code is our real code.

What is implemented? Are you tracking it? We to have this feedback loop.

Mm-hmm. So we didn't want any translators in the middle that will lose information that will, that will lose this, this feedback, pure feedback loop. So, and, and that's where we found our, uh, really this, our, our new tools have enabled us to do this.

Our new configuration management platform enabled us to do this, treat our net network as code, keep it as code, and feed us back to information about our code, how it's implemented, any deviations, any, any drifts, things like that. And, and just to be really clear, you know, you, you went down the path of going with Nokia's Sr. Linux as a switch in router operating system and event driven automation, or EDA as the, the management and automation platform.

And there's some really interesting connections there from a Kubernetes perspective, from getting away from having to go testing with physical equipment in the lab. Um, I know you can speak to at least both those issues. What, what did you get out of that, you know, out of, um, Sr.

Linux with EDA to drive that forward? Okay, so, so Edda enabled us to, to build, I was talking about the, the, you know, the software development cycle mm-hmm. Where you have a production environment and you have a development environment.

Uh, we really wanted our, our development environment to be a copy of our production, but we don't have to, we don't want to build a lab mm-hmm. That is a development environment. I mean, we've got data centers with hundreds of, of switches in there.

Sure. And we didn't want to go and build a lab or build a scale down of the lab. Sure.

A scale down can, can sometimes work, but sometimes in cases where we do migrations, for example, right. We, we really need every, we need to understand every node. So, so either provide us with this idea of a digital twin mm-hmm.

A true digital twin, running the same code, same everything. And the nice thing about it is the intent, the intent, the, the network intent that I'm feeding into the production environment. Mm-hmm.

I can feed the same network intent to my digital twin. Mm-hmm. No, no changes at all in anything.

I don't have to, to mess it around or tell it or massage it to fit with this digital twin. Sure. Just the same code.

Put it in the digital, digital twin, and then I can play with that code. I can, I can make changes in that code. I can experiment, I can run traffic on, on this digital environment that is a true replica of production.

And once I'm happy, then I can merge into production knowing that my design works well. So I can, I can test things that, you know, routing to low balancers, to firewalls, uh, different server configurations. I can do that in the digital environment Yep.

And, and feed it back into production. So, so, so either this idea of a digital twin was very powerful, very, very powerful. And, and especially in migrations, it was, Yeah.

You're using the same control plane that you're using on the physical switches and you're feeding it the same configs and to be able to play what if in the digital twin, that's a, that's a huge enabler. Right. And, uh, And the nodes are running the same code as the production node, as the real Sr.

Linux knows. And you could even change that rev of code. Right.

And still see those changes reflected in the digital twin. Yes. Yep.