That's why we need to take this back from the vendors so that we don't have that mess - or atleast less mess - oh and no openconfig support then your kit won't be deployed into the network - great news on Junipers work - they have really got this and are doing a great job.
Sent from my iPhone > On 25 Sep 2015, at 15:45, Nick Hilliard <n...@foobar.org> wrote: > >> On 25/09/2015 14:14, Neil J. McRae wrote: >> On the network side each individual atom is simple enough to automate >> (but rarely provides any value) but the area we have completely failed >> as an industry is pulling those atoms together as a set of services or a >> capability outcome, mostly down to our lack of ambition to change how we >> create and operate networks (interconnect and peering are top of the >> list for change in my view). > > it's easy enough to complain about tools and constructs not being there, > but there's another fundamental problem, namely that the config semantic > requirements of the network are complicated relative to the simplicity of > the config atoms. Mixing in different language interpretations from > different vendors adds to the mess. > > Nick