[c-nsp] IOS(-XE) 'configure replace' robustness

[Saku Ytti]

On 4 May 2017 at 10:43, James Bensley <jwbensley at gmail.com> wrote:

Hey,

> Yeah me too! This is part of a greenfield build that has CSR1000v as
> CPEs and ASR9000s as PEs. I've had moderate success with ASR9000s
> using a mixture of OpenConfig YANG models and Cisco's proprietary YANG

YANG is not option for us, we need 100%, then from available options,
we choose something. And only available for 100% is CLI. We update
millions of lines of ASR9k every day with only ever doing full
replacement of entire config. It works quite well, it is free from
catastrophic failures, but sometimes it won't accept new config or
parses it incorrectly. Cisco always treats these as bugs, but to my
frustration these are handled by component teams, not some generic
infrastructure issue.
I feel like IOS-XR is missing layer of abstraction or two. Like if you
can't move BGP remote-as from neighbour to group in single commit,
this is problem for BGP component team, if you cannot renumber GRE
interface number, this is problem for GRE/tunneling team, if order of
tacacs servers in new config is not honored (it remembers something
from old config) this is problem for TACACS team. I don't think this
is sustainable way to do it, they should create another layer of
abstraction(s) so that component teams would not have to think about
configuration issues at all.

I am not at all interested in YANG, because there is no 100% coverage
and I need to change whole config. And instead of doing something via
YANG and something via CLI, it's just easier to do all from CLI.
If this was done the right way, from single truth source the could
machine generate 100% YANG models with 0 human effort. Then merge the
output with standard models as written by humans. So you'd always have
full coverage and standard models when possible. I fear that YANG will
just become new MIB without by-design 100% coverage.

-- 
  ++ytti