How to commit config? Merge/replace?

kwatsen commented 8 years ago

Slide 10 from the zero touch preso @ 95 had:

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

Kent

kwatsen commented 8 years ago

So I’ve added the following leaf - any thoughts?

      leaf config-handling {
        type enumeration {
          enum merge {
            description 
             "Merge configuration into existing running configuration.";
          }
          enum replace {
            description
              "Replace existing running configuration with passed
               configuration.";
          }
          enum edit-config {
            description
              "Process configuration as an <edit-config> document.";
          }
          enum yang-patch {
            description
              "Process configuration as a YANG Patch document.";
          }
        }
      }

I wish edit-config and yang-patch could be options/features, but this doesn’t reduce the number of formats that devices would need to support, as limiting what a specific bootstrap-servers supports doesn’t limit what other bootstrap-servers might support...

Kent

kwatsen commented 8 years ago

From: Netconf netconf-bounces@ietf.org on behalf of Kent Watsen kwatsen@juniper.net Date: Thursday, August 11, 2016 at 8:32 PM To: "netconf@ietf.org" netconf@ietf.org Subject: Re: [Netconf] zerotouch/12: How to commit config? Merge/replace?

Let’s close all the open issues for the zerotouch draft. Starting with low-hanging fruit first makes sense... For this particular issue, it seems to me that the simplest and easiest solution is to just support the ‘merge’ and ‘replace’ options for now (no edit-config or yang-patch). Though not discussed previously, I also replaced the ‘default replace’ with a ‘mandatory true’, as there truly can be no preferred option here (it’s a customer-driven choice). So, the net result is: leaf configuration-handling { type enumeration { enum merge { description "Merge configuration into existing running configuration."; } enum replace { description "Replace existing running configuration with the passed configuration."; } } mandatory true; description "This enumeration indicates how the server should process the provided configuration."; } I’ll assume this approach is confirmed if no objection is raised by the end of next week. Thanks, Kent From: Netconf netconf-bounces@ietf.org on behalf of Kent Watsen kwatsen@juniper.net Date: Wednesday, July 6, 2016 at 9:50 PM To: "netconf@ietf.org" netconf@ietf.org Subject: Re: [Netconf] zerotouch/12: How to commit config? Merge/replace? So I’ve added the following leaf - any thoughts? leaf config-handling { type enumeration { enum merge { description "Merge configuration into existing running configuration."; } enum replace { description "Replace existing running configuration with passed configuration."; } enum edit-config { description "Process configuration as an document."; } enum yang-patch { description "Process configuration as a YANG Patch document."; } } } I wish edit-config and yang-patch could be options/features, but this doesn’t reduce the number of formats that devices would need to support, as limiting what a specific bootstrap-servers supports doesn’t limit what other bootstrap-servers might support... Kent From: Netconf netconf-bounces@ietf.org on behalf of Kent Watsen kwatsen@juniper.net Date: Wednesday, June 29, 2016 at 6:53 PM To: "netconf@ietf.org" netconf@ietf.org Subject: Re: [Netconf] zerotouch/12: How to commit config? Merge/replace? 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 netconf-bounces@ietf.org on behalf of Kent Watsen kwatsen@juniper.net Date: Wednesday, May 11, 2016 at 7:03 PM To: "netconf@ietf.org" netconf@ietf.org 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 . 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

netconf-wg / zero-touch

How to commit config? Merge/replace? #12