Practical usage of interface 'type' and the association to IETF -> IANA types

[earies]

Per OpenConfig community agenda for 2023-01-05

Since the initial publish of the openconfig-interfaces modeling, the following mandatory nodes have existed

module: openconfig-interfaces
  +--rw interfaces
     +--rw interface* [name]
        +--rw config
        |  +--rw type    identityref
        +--ro state
           +--ro type    identityref

Which is defined as the following 2-stage identityref back to iana-if-type

leaf type {
  type identityref {
    base ietf-if:interface-type;
  }
  mandatory true;
  description
    "The type of the interface.

    When an interface entry is created, a server MAY
    initialize the type leaf with a valid value, e.g., if it
    is possible to derive the type from the name of the
    interface.

    If a client tries to set the type of an interface to a
    value that can never be used by the system, e.g., if the
    type is not supported or if the type does not match the
    name of the interface, the server MUST reject the request.
    A NETCONF server MUST reply with an rpc-error with the
    error-tag 'invalid-value' in this case.";
  reference
    "RFC 2863: The Interfaces Group MIB - ifType";
}

For a number of years, there has been motivation to remove external dependencies from OpenConfig modeling. While on one aspect, leveraging others work for reuse is good practice, however it also creates dependencies which can prove difficult to control over time (ref: Redefinition of relevant IETF types modules) especially if the intent of the 2 projects diverge.

The iana-if-type module version 2017-01-19 currently defines 285 possible identities for use while OpenConfig related use-cases only have necessity for around 5 true interface "types". Deviations cannot convey which identities are supported/not-supported thus each implementation needs to implement custom guardrails to start that can only be signaled out-of-band or via error handling to the consumer/client.

Aside from the vast list of potential types, implementations generally have not supported specifying the "type" as a r/w object but rather the interface nomenclature drives the type followed by potential encapsulations where applicable. (You cannot for instance dictate that an interface named et-0/0/0 can be of type softwareLoopback)

Since the model node is marked as mandatory means the payload MUST include this leaf when provisioning an interface (which in the case of physical interfaces are often already provisioned at time of hardware initialization). In most cases, what you will find is that this node does not translate to anything meaningful within the implementation from a configuration perspective (e.g. no-op). Essentially these cases create what one would consider a bad API. You are giving the perception that you instructed the server to do something that it is blindly accepting and the client is re-iterating for no good reason.

There are a number of cases of leaf nodes within the OpenConfig model sets that result in no-ops for various implementations but when tied to a leaf node that is mandatory as such means that a client must define something and that a server will likely do nothing with that value calls into question the existence and purpose in the first case.

For r/o objects, this can still be an attractive attribute to understand which interfaces are of which type dictated by the system but under most circumstances this is an object that is not editable.