[Question] Why do Openconfig Yang models mix config and state leaves in the same yang tree?

[pedroaston]

Question

Why do Openconfig yang models mix configuration containers with state ones in the same yang tree?

Example of the current IS-IS OC model (path >> /network-instances/network-instance/protocols/protocol/isis/):

"openconfig-network-instance:global": {
    "afi-safi": {
      "af": [
        {
          "afi-name": "openconfig-isis-types:IPV4",
          "config": {
            "afi-name": "openconfig-isis-types:IPV4",
            "enabled": true,
            "max-ecmp-paths": 0,
            "safi-name": "openconfig-isis-types:UNICAST"
          },
          "safi-name": "openconfig-isis-types:UNICAST",
          "state": {
            "afi-name": "openconfig-isis-types:IPV4",
            "enabled": true,
            "max-ecmp-paths": 0,
            "safi-name": "openconfig-isis-types:UNICAST"
          }
        },
        {
          "afi-name": "openconfig-isis-types:IPV6",
          "config": {
            "afi-name": "openconfig-isis-types:IPV6",
            "enabled": false,
            "max-ecmp-paths": 0,
            "safi-name": "openconfig-isis-types:UNICAST"
          },
          "multi-topology": {
            "config": {
              "enabled": false
            },
            "state": {
              "enabled": false
            }
          },
          "safi-name": "openconfig-isis-types:UNICAST",
          "state": {
            "afi-name": "openconfig-isis-types:IPV6",
            "enabled": false,
            "max-ecmp-paths": 0,
            "safi-name": "openconfig-isis-types:UNICAST"
          }
        }
      ]
    },
    "config": {
      "instance": "1",
      "level-capability": "LEVEL_2",
      "net": [
        "01.0100.0000.0000.00"
      ]
    },
...
}

Example of segregated yang for config and state:

(config yang example)
{
  "openconfig-network-instance:global:config": {
    "afi-safi": {
      "af": [
        {
          "afi-name": "openconfig-isis-types:IPV4",
          "enabled": true,
          "max-ecmp-paths": 0,
          "safi-name": "openconfig-isis-types:UNICAST"
        },
        {
          "afi-name": "openconfig-isis-types:IPV6",
          "enabled": false,
          "max-ecmp-paths": 0,
          "safi-name": "openconfig-isis-types:UNICAST"
         },
        "multi-topology": { 
          "enabled": false
         }, 
        }
      ]
    },
    "instance": "1",
    "level-capability": "LEVEL_2",
    "net": [
      "01.0100.0000.0000.00"
     ]
  },
...
}

(state yang example)
{
  "openconfig-network-instance:global:state": {
    ...
    "circuit-counters": {
      "adj-changes": 0,
      "adj-number": 0,
      "auth-fails": 0,
      "auth-type-fails": 0,
      "id-field-len-mismatches": 0,
      "lan-dis-changes": 0,
      "max-area-address-mismatches": 0,
      "rejected-adj": 0
     },
...
}

From the point of view of a telemetry collector and of a configuration agent, the segregated approach seems to be the best one from a pragmatic point of view. Also some router vendors who have their own yang models seem to be choosing this path.
What was the rational to choose the current approach by Openconfig?

Thanks

[dplore]

See https://openconfig.net/docs/guides/style_guide/#naming

The motivation for this style is to emphasize the correlation of monitoring and configuration for authors and readers of the model.

See openconfig/gnmi#169 for a proposed update to gNMI to subscribe to config and state separately.

[pedroaston]

Hello @dplore,

thanks for the feedback 😃 The gNMI pull request you linked is relevant to some of the issues I have faced when working with gNMI and OC models from a NMS POV. I will try to contribute there on the related issues.