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.

[robshakir]

A couple of reasons that we ended up with a configurable type (making no statement as to whether we should consider making this non-mandatory).

• containers such a ethernet and routed-vlan and aggregation have when statements that depend on the type of the interface, this must be a r/w node according to YANG language rules. if we remove this leaf as mandatory, it will likely not be useful to have such when statements that allows for some creation of potentially invalid data instances (e.g., ethernet container being used on a non-Ethernet link type such as a loopback).
• currently, there is an explicit validation that can be performed to say that the client is expecting this interface to be of type X. prior to modelled data, this information was essentially implicitly implied by the name of the interface - having a type explicitly specified allows, outside of the type, allows this kind of validation without magic name parsing.

[github-actions]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.

[earies]

Commenting to keep active as this is still an item worthy of discussion/closure