[grnog] GRNOG9 Network Automaiton discussion

[Andreas Polyrakis]

Hi Nikos,

On 11/12/2019 9:36 π.μ., Nikos Leontsinis wrote:
>
> Ερωτηση προς τους ομιλητες του networkautomation:
>
> Τι κανουμε με τα cornercases;
>
> We didn’t discover America in 2019. Python and most of the tools did 
> exist well before that even in 2000
>
> Why we were not automating the network  back then?
>
> Could it be the answer is that the network at the time was more of an 
> enabler and now became more of
>
> a commodity?
>
This is also true. I would mostly focus on the following:

- immaturity of tools. Today we have frameworks, libraries and 
abstraction levels (eg ansible, napalm) that allow you deal with the 
essence of network automation without programmatically worrying about 
transport, errors etc. All these are handled in a much more abstracted 
layer. We are also much more mature in XML, and I don't think that yaml 
even existed back then. This also allows you not to share experience and 
code and not rediscover the wheel. Nosql, and JSON play a significant 
role too. Many tools (eg NMS) now have a XML or JSON api, that allows 
integration. Last but not least, network gear is much more mature for 
automation -- see non monolithic OS, netconf, agents or python running 
within the device, telemetry and countless more features. Back then we 
had CLI and SNMP.

- Necessity: The number of devices has grown; the complexity of services 
has grown. Configurations have grown 10x or more times bigger. Modern 
services have so many parameters that it is almost impossible to tweak 
by hand or memory. For instance, EVPN/VXLAN and SDN are impossible to 
deploy in scale without automation. At the same time, the need for a 
reliable network has exploded. Back then a few hours of downtime might 
be ok, now even a few seconds have a huge impact.

> How much flexibility are we prepared to sacrifice with automation?
>
Valid point. This is a balance that has to be found for each network. 
Networks that successfully automate have found this balance, otherwise 
automation would have ollapsed in practice.

The question however, is not that much related to automation, but to 
service catalog: How willing are you to provide flavors or variations of 
services not described in your service catalog?

> How can we  reconcile business requirements that require design 
> deviations and still ensure consistency
>
> and data model driven adoption?
>
Again, this translates to service catalogue. There are companies that do 
not wish to have a service catalogue because they want to be flexible to 
provide any service that the customer might imagine. For such cases, 
automation is much more difficult and with limited scope.
>
> If we cannot how much design/model deviation can we tolerate?
>
It is hard to answer in a few sentences, but it is doable. You need to 
have a relatively stable service catalogue, but small or transient 
deviations can be handled in various ways.

At GRNET, for instance, we had the option for something like an 
"override" file per device, which we would use as a last resort for 
commands that could not be generated by our automation, just to handle 
such kind of exceptions. Still, exceptions on such a file where much 
better than exceptions arbitrarily "lost" within the configuration of 
the router: They were gathered together so that you could not miss 
them;  they were commended so that we knew why they were there; and git 
could track when and who inserted them into our network.

> There is a dark side of automation that none wants to talk about…
>
Actually we do :-) Most automation presentations talk about such things, 
although they do not name it "dark side" but "challenges", "todo", 
"caveats"...

But I get your point. Maybe we can have a panel at next GRNOG about that.

BR,


> nikos
>
> This email is from Equinix (EMEA) B.V. or one of its associated 
> companies in the territory from where this email has been sent. This 
> email, and any files transmitted with it, contains information which 
> is confidential, is solely for the use of the intended recipient and 
> may be legally privileged. If you have received this email in error, 
> please notify the sender and delete this email immediately. Equinix 
> (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA Amsterdam, The 
> Netherlands. Registered in The Netherlands No. 57577889. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nogalliance.org/pipermail/grnog-members/attachments/20191211/f918ac6b/attachment.html>