[j-nsp] Automation - The Skinny (Was: Re: ACX5448 & ACX710)

[Saku Ytti]

On Fri, 24 Jan 2020 at 10:33, Mark Tinka <mark.tinka at seacom.mu> wrote:

> Since about 2012, every time we've felt we've come close to finding an

In my opinion we do roughly the same thing, the same way in networks,
with the same protocols since my start of career in 90s, very little
has changed and you could drop competent neteng from 90s to today and
they'd be immediately productive. Compare this to what has happened to
compute the difference is striking.

> My 1+1 assessment of all of these issues is, I believe, down to the fact
> that the industry wants to automate in an open standards manner, where

People who think that netconf and yang are solving big problems and
are key to solve automation probably haven't done much automation.
Roughly netconf is new snmp and yang is new mib, what ever they enable
could have been enabled by existing protocols decades ago, the
advantages are modest and will remain so. The key enabler for
automation is device accepting arbitrary new B config when it is
running arbitrary new A config and transition there hitlessly.
Generating full new config from DB+template is trivial problem, trying
to be aware of network state and move from arbitrary state A to
arbitrary state B with minimal amount of changes is hard and
unnecessary problem.


If/when network becomes more cloudified, more as-a-service, where you
use API to turn up your own active devices and circuits where you
want, when you want, instead of owning anything and once those
proprietary APIs get some subset standard APIs we'll probably start to
see openstack, kubernetes type of complexity explosion in networks
too. But as long as we keep owning the network most will keep running
it CLI jjockey network, touch when you must, but in many cases no one
touches it for weeks or months.


-- 
  ++ytti