Subject: Re: [Netconf] zerotouch/12: How to commit config? Merge/replace?

From: Kent Watsen <[email-masked]>
Date: Wed, 29 Jun 2016 22:53:29 +0000

Trying to move this discussion forward.

I’m still prefer (b) for the reasons listed below, but it may be possible to do something in between (b) and (c).  In particular, a top-level flag could allow for edit-config and yang-patch options also.

OLD:
              +--:(bootstrap-information)
                 +--ro bootstrap-information
                    +--ro boot-image
                    |  ...
                    +--ro configuration
                    +--ro script?          string

NEW:
              +--:(bootstrap-information)
                 +--ro bootstrap-information
                    +--ro boot-image
                    |  ...
                    +--ro config-handling  enum {replace, merge, edit-config, yang-patch}
                    +--ro configuration
                   +--ro script?          string

Thoughts?  - is it worth it?

Thanks,
Kent

From: Netconf <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Wednesday, May 11, 2016 at 7:03 PM
To: "[email-masked]" <[email-masked]>
Subject: [Netconf] zerotouch/12: How to commit config? Merge/replace?

https://github.com/netconf-wg/zero-touch/issues/12

Slide 10 from the zero touch preso @ 95 had:

  Options:
A. Hardcode ”replace”                        // always works, but large in size
B. Use a top-level flag                         // let deployments decide
C. Use edit-config or yang-patch?     // is this much granularity needed?

The minutes note that Rick Taylor prefers the last option, stating that the configuration can be big.

But let's consider option (b) in the context of the config being big.   If the top-level flag is 'merge' and the config is huge, then it's effectively the same as <edit-config>.   Otherwise, if the top-level flag is 'replace' and the config is huge, then the amount of factory-default config that gets replaced is relatively small.  So it seems that option (b) is equally viable in the context of huge configs.

I personally prefer option (b), because I think that it's better in this case to not require the client to have to understand edit-config or yang-patch.  Recall, the device is the HTTP client, and the logic that implements the bootstrapping code may be different than the logic that knows how to process NETCONF or RESTCONF, at least this how I've seen it implemented...

Thoughts?

Kent