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

[James Bensley]

On 4 May 2017 at 10:38, Saku Ytti <saku at ytti.fi> wrote:
> 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.

My main problem is legacy key, we have thousands of IOS devices that
don't work so well for this, see below...

> 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'm surprised this isn't the case!

> 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.

I'm right with you there on 100% coverage being important and that
only the CLI provides that right now for all Cisco products, also I'm
100% in agreement that full config replacement is the only way it
should be done if we have to use the CLI for config transport. The
problem is, the majority of infrastructure is legacy (exclude the
greenfield project I have been talking about so far, all our existing
infrastructure needs to be brought into scope in the long term, moving
forwards we can say "only deploy kit that has full X technology
support" but doesn’t help with all the existing kit).

To bring legacy equipment on board we have to go the CLI route as you
have. Maybe you know something I don’t, maybe commenters are right and
I’m mental, but I’m happy to use a mix of CLI and API to make that
transition.

-Legacy PEs are CLI only.
-A recently deployed PE might have API support for some percentage of
features but not all.
-A brand new PE being deployed today might have full API support for
all features we need/use.

I can’t wait until all our legacy kit is upgraded to a device
make/model with full API support and then switch the entire estate
from CLI config transport to API transport.

I would expect our config platform to push config to a device, it
knows which features this devices supports via API and which via CLI,
if all the config we require to push is supported via API then use
that (load up the YANG models and serials as JSON over gRPC for
example), else fall back to CLI (load up the Jinaj2 templates and
serialise as text over SSH for example).

100% YANG coverage would be great and I hope it doesn’t flop, however
even partial is better than nothing. CLI is not faultless as you have
stated, and nor is API driven work, but the error rate should be much
lower for features that are supported via API, so I’d like to move as
much as possible to API driven work, to reduce that fault/error rate
and hopefully we will end up with 100% API driven operations in the
coming years, I’m not going to wait for there to be 100% coverage then
switch to API transported configuration, that approach may ensure that
there is never 100% coverage.

Cheers,
James.