search

openconfig / reference

This repository contains reference implementations, specifications and tooling related to OpenConfig-based network management.
Apache License 2.0
155 stars 88 forks source link

Add special case for origin CLI #174

Closed dplore closed 1 year ago

dplore commented 1 year ago

Clarify use of origin CLI when mixed with other origins.

Resolves https://github.com/openconfig/featureprofiles/issues/740

jsterne commented 1 year ago

One consequence of origin 'CLI' being a mix of: 1) schema, and 2) instance data format/encoding is potential confusion when OpenConfig data is sent using CLI format. (is that OpenConfig or is it CLI?).

IMO the "precedence" rule of native over OpenConfig should be about native schema taking precedence over OpenConfig schema (regardless of format/encoding).

Consider a single Set request with the following (in this order): 1) update with origin 'CLI', but the data contains purely OpenConfig data (in CLI format) 2) update with origin 'OpenConfig' [and there is overlap/conflict between (1) and (2), e.g. (1) sets mtu to 1504 and (2) sets mtu to 1492]

By the current text it would mandate that the configuration in (1) take precedence. But that seems to somewhat conflict with the general gNMI 'Set' approach of processing the updates in order.

robshakir commented 1 year ago

Is there a simplification that we can write here that meets the same requirement whilst not having to deal with many edge cases that seem irrelevant?

  1. We support only replace for origin cli.
  2. replace with origin cli MUST be first in the SetRequest.
  3. Application of another schema -- OpenConfig/vendor native models is then applied on top of this new candidate that was formed by the replace of the CLI. (i.e., replace cli means "replace everything on the device even if it's not in this tree").

This gives us a much simpler solution - that makes not just the origin: "cli" specific but also the semantics of a full replace.

vcheny commented 1 year ago

Is there a simplification that we can write here that meets the same requirement whilst not having to deal with many edge cases that seem irrelevant?

  1. We support only replace for origin cli.
  2. replace with origin cli MUST be first in the SetRequest.
  3. Application of another schema -- OpenConfig/vendor native models is then applied on top of this new candidate that was formed by the replace of the CLI. (i.e., replace cli means "replace everything on the device even if it's not in this tree").

This gives us a much simpler solution - that makes not just the origin: "cli" specific but also the semantics of a full replace.

As discussed with @robshakir offline, it may worth clarifying how we can support

  1. The whole existing config including OC and VC can be replaced.
  2. The non-overlapped VC config will not be overwritten by OC.
  3. Handling VC config that is overlapped with OC.

Looks like replace cli can achieve 1. i.e. it will remove everything on the device including VC and OC. And 2 and 3 can be achieved by only allowing OC update when replace cli is present. This would also mean OC will overwrite VC if they are overlapped.

dplore commented 1 year ago

I will close this PR and make a new one with a more narrow and simple use case like @robshakir suggests. Our goal is to define one behavior to meet our operational need for a full config replace containing CLI and OpenConfig. In addition, now that we have learned from the comments and from some internal exploration of concrete configuration scenarios we can provide some concrete examples of interaction between CLI and OC.

jsterne commented 1 year ago

In previous calls we were never leaning towards OC having precedence over VC. It was always VC having precedence over OC (and also some discussion of potentially considering an error if there is overlap).

dplore commented 7 months ago

https://github.com/openconfig/reference/pull/188 was introduced to replace this PR