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

Reply via email to