gSII backwards compatability

[nleiva]

Thank you for presenting this proposal during the network operators’ call. The increased flexibility and speed this API offers are certainly appealing. What migration path do you envision for existing systems and operators?

It appears this change would not be backward compatible. Could you confirm this?

If we assume a network operator is tracking the active state of an interface via state/enabled. With the introduction of dynamic/enabled, would operators need to compute the definitive state of an interface by applying logic on multiple fields? This could make existing monitoring systems obsolete, increasing the cost of adoption. I think requirement [R4] aims to address the relationship between dynamic and applied states. Could you elaborate on how this will be implemented to minimize confusion and maintain clarity in state reporting?

Thanks,

[robshakir]

Thanks for the review Nicolas.

I'm not quite sure why this would be backwards-incompatible.

• For writers that are using gNMI, there is no change needed to keep writing to the config paths that are defined in the data model. In the scenario that adoption of gSII happens, then the paths that are used are explicitly defined to be different (i.e., we define a new set of containers called volatile that cover this functionality).
• The definition in the motivation document essentially says:
  • config/enabled continues to be the intended state as written by a system that manages the persistent stable state of the device (this is referred to as "dynamic" configuration in the bootz specification).
  • volatile/enabled gives us the new path to be able to write state that is not persisted across reboots.
  • state/enabled gives us the currently running state of the device (applied config per our previous definitions). Devices that support volatile paths must transition to apply logic as shown in the pseudocode below. In this case, if volatile/enabled simply isn't used then the value of state/enabled doesn't change.

    value = None
    if path("volatile/enabled") is not None:
      value = value_of("volatile/enabled")
    elif path("config/enabled") is not None:
     value = value_of("config/enabled")
    apply_value_to_system_and_update(path("state/enabled"), value)
    

The only case in which I think that there's some consideration needed is if there are systems that are implemented that apply a loop to say "if the value of state/enabled does not match the value of config/enabled then take some action" -- since in these cases the system would not know about volatile/enabled and hence try and override the volatile state. I'm not aware of such systems -- because there are multiple reasons that we could end up in a situation of state/enabled and config/enabled not matching. Particularly: some precondition is not met (linecard is not inserted); the device is slow to converge the configuration (commit+application is still in progress) etc.

The above logic is reflected in the motivation doc.