allow-config-mismatch extension

[dplore]

It is common for hardware to be installed in a device which does not 100% match the applied or newly set configuration. In this scenario it is desirable to still accept the configuration and return a warning.

For example, as a network operator I want to allow a device to have unexpected interface transceivers installed and still be able to push configuration changes to a device. Without this behavior, a single unexcepted transceiver installed in a device would block all configuration changes. Blocking these configuration changes can be much more operationally impacting than having a single interface be unavailable.

One way to address this might be with a yang extension to annotate containers or leaves which should allow a configuration mismatch with the underlying hardware.

Change Scope

• Introduce a new OpenConfig yang extension called allow-config-mismatch
• Annotate interfaces and subinterfaces containers to include allow-config-mismatch

[OpenConfigBot]

Major YANG version changes in commit c2d28df:
openconfig-extensions.yang: 0.7.0 -> 1.0.0

[earies]

I'm not sure I see the value of this extension but rather this is underlying implementation dependent behavior.

Configuration (r/w) values should not have dependencies on current operational state (r/o) but rather either schema restrictions that impose dependencies or the underlying platform restrictions itself.

I believe the intent (correct me if I'm wrong) of this PR is describing what at least some implementations (JUNOS/EVO) have as first class principles whereas you can provision whatever you like as long as it adheres to the schema/platform restrictions but would not take effect should there either be a mismatch or the HW is not installed or in an active state.

Is there a specific issue that spurred the proposal for this extension? If this were an extension, I believe the scope of where it is applied would grow far outside of the proposed annotations and in the case where implementations already adhere to this protocol, would have no effect.

and return a warning

How would a warning be accomplished or helpful (say via gNMI set)? In JUNOS/EVO, if the configuration adheres to the schema and backend validation and in cases where it does not apply to the hardware, the configuration is accepted but annotated when retreived.

[dplore]

Thanks for the comments and good points! This PR is meant to inspire review of this subject and see how we can formalize expectations around at least this very specific scenario and if possible, generalize it as appropriate.

The scenario with undesired behavior:
A 100G interface transceiver is installed into one port on a device. A full device configuration is then Set with this port configured to be a 4*100G breakout-mode. Since the 100G transceiver cannot support this mode, the configuration was rejected (grpc error INVALID_ARGUMENT). This is operationally quite bad when using a "full configuration replacement" strategy as it results in blocking all configuration changes.

Desired behavior:
The configuration with the mismatched breakout-mode config should be accepted resulting in the affected port being down/in an error state. The relevant config leaves should show the desired config and the state leaves should show the operational configuration.

For reference here's an example breakout-mode configuration that should always be accepted, regardless of the underlying hardware capability.

{
  "components": {
    "component": [
      {
        "config": {
          "name": "Port0"
        },
        "name": "Port0",
        "port": {
          "breakout-mode": {
            "groups": {
              "group": [
                {
                  "config": {
                    "breakout-speed": "SPEED_100GB",
                    "index": 1,
                    "num-breakouts": 4,
                    "num-physical-channels": 4
                  },
                  "index": 1
                }
              ]
            }
          }
        }
      },

[jsterne]

IMO we should not have a new extension for this. That should be the expected behavior. Accepting a config should not depend on state (e.g. what transceiver is plugged in, what linecards are plugged in, etc).
That config is perfectly valid (as a self contained config). Someone could plug in a different (correct) transceiver and it would all work.

[earies]

IMO we should not have a new extension for this. That should be the expected behavior. Accepting a config should not depend on state (e.g. what transceiver is plugged in, what linecards are plugged in, etc). That config is perfectly valid (as a self contained config). Someone could plug in a different (correct) transceiver and it would all work.

Agreed - the config is valid assuming overall platform + model support and should be accepted. When such a case occurs, you would detect by way of the difference or lack of state nodes (the intent behind the config/state OC design). I'd say how one drills deeper as to "why" is worth discussion possibly as this would either be silent, seen in logs or in our case - annotations attached to data nodes in the config db only in some cases (could be a use for extending more openconfig-metadata).

Another common case outside of a true mismatch is "pre-provisioning" - the element should accept the configuration and when the resource it applies to comes online at a later date, gets applied...

But I see all of this as implementation detail which cascades into requirements that likely sit outside of OC charter (at least outside of the data-models)

[ElodinLaarz]

Discussed at OC Operators Meeting on March 3rd, 2026:

Seems useful to make the behavior that we want explicit / part of the default expectations of OpenConfig (for this particular interface example here).

The extension change proposed here should be replaced with some specification.

It seems tricky to have an expectation for handling generic config mismatches, but for this particular example, as we have seen issues in the past, it seems useful to explicitly describe the desired behavior.