On Fri, 24 Jan 2020 at 10:33, Mark Tinka <mark.ti...@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp