Network Automation: a Service Provider Perspective

Antti Ristimäki left an interesting comment on Network Automation Considered Harmful blog post detailing why it’s suboptimal to run manually-configured modern service provider network.


I really don’t see how a network any larger and more complex than a small and simple enterprise or campus network can be developed and engineered in a consistent manner without full automation. At least routing intensive networks might have very complex configurations related to e.g. routing policies and it would be next to impossible to configure them manually, at least without errors and in a consistent way.

With automation even the most complex configurations can be presented with a simple abstraction and should one need to implement any architectural change in the network, one can build the logics only once and let the automation multiply it into the running configs. We have a lot of examples of such, for example policy frameworks for BGP SOO filtering, BGP large community based selective route filtering, prefix segment injection with correct SIDs, RPKI ROA validation configurations etc. Without automation it would be also very difficult to enforce the desired configurations and would result in an opportunistic network where certain configurations are only applied if an engineer has remembered to, or cared to, configure them.

By the way, I think that “automation” is not actually the best word to describe this whole thing and I’d rather talk about programmatic approach to network configuration. Ironically, I think that Software Defined Networking would be a perfect term, if only SDN hadn’t gain such a bad reputation during recent years when it was used exclusively for just about anything. Maybe “network configuration as a code” would describe pretty well what is usually referred to as “automation”.


Not surprisingly, what he wrote matches what I’ve been explaining in automation webinars and online course for years:

  • Figure out what you want to do
  • Define the services the network has to offer
  • Create a high-level data model describing the services
  • (Optional) Transform services data model into devices data model to make your device configuration templates more palatable
  • Create device configuration templates that transform your high-level data model into device configurations
  • Set up a workflow that deploys device configurations, either in a maintenance window or on every change
  • (Optional) Refactor the high-level data model into 4NF/5NF and store services data in a transactional database instead of a bunch of YAML files in a shared folder
  • (Optional) Create a user interface friendlier than YAML/vi to modify the high-level data model
  • (Optional) Call your high-level data model intent and create a buzzword-bingo-winning white paper or a self-congratulating conference talk

You might have noticed that I haven’t mentioned a popular 7-letter tool or a must-learn 6-letter programming language – low level tools don’t matter nearly as much as processes, workflows and architectures.

2 comments:

  1. Automation is mainly about money - I am talking about rather big networks, not small one-man automated networks.

    If you want to introduce automation in your network you need to create a Business Case and talk to your managers. At the beginning it's expensive so without managers support you can forget about full blown automation.

    You need to have developers (programming part) mixed with network engineers (network knowledge). This process never stops as long as the network or network based product is supported and developed. You will never reduce your stuff as long as you keep your network running & updating - new features you add will make your team busy.

    You won't succeed if your manager do not understand the benefits because, again, it's about money (both investing & savings). And in case of big networks it is also about surviving because human error costs money as well.

    BTW. I am doing automation for more than 15 years in the mixed team (developers & network engs) for network based systems of size up to 10 000 or more nodes. We started with the automation from day one, years before the Automation was discovered by the Gartner. This decision was driven by the fact that our networks were to big to handle configuration process it manually. The tools has changed over the years but they do not matter here as Ivan mentioned. Automation is about your mindset...

  2. At the crossroads for automation, again. Different companies, same question(s). How and how to make the barrier of entry low, considering 'we have done it like this for years' questions. Multi-vendor - you name it, we have it; old software; REST API enabled (with a call for every bloody thing available, nothing task based). The main question is - I want it to look perfect and everyone will write playbooks. No, they will not. And they have to benefit from move right away in cases of old workforce/CLI jockeys (nothing bad about this, I like CLI, that is why I know when not to use it). How do I make sure that intended configuration does not interfere with 'no change in state' work - replacing a failed linecard, traffic shifting a device with arbitrary routing protocol running on it? All that with minimal investment in developers or netdevops...

    Replies
    1. I took my sweet time to write a proper response (and sometimes that takes months), but then figured out I sort-of answered in 2018 😉 (the "tons of things you can do" section)

      https://blog.ipspace.net/2018/11/dont-let-automation-snowflakes-stop-you.html

Add comment
Sidebar