Interface MTU type width inconsistency with IPv6 MTU and implementation scenarios

[earies]

Today, the interface and subinterface MTU in openconfig-interfaces is defined as uint16

leaf mtu {
  type uint16;
  description
    "Set the max transmission unit size in octets for the
    physical interface.  ...

While the IPv6 MTU in openconfig-if-ip is defined as uint32 (to accommodate RFC 2675 jumbograms)

leaf mtu {
  type uint32 {
    range "1280..max";
  }
  description
    "The size, in octets, of the largest IPv6 packet that the
    interface will send and receive.

And the IPv4 MTU similarly as uint16

leaf mtu {
  type uint16 {
    range "68..max";
  }

This presents two issues:

• A child node (ipv6/mtu at uint32) can express values that the parent interface MTU (uint16) cannot represent. The contract that a child/IP MTU should not exceed the parent/link MTU is not expressible when the child has a wider type than the parent. There is no must or when constraint tying these together but even outside of that, the types themselves make it impossible to enforce such a relationship consistently.
• Current operating systems use wider types for the link-level MTU. As an example, in the Linux kernel struct net_device defines mtu as unsigned int (32-bit). The default loopback interface MTU in Linux is 65536 which already exceeds uint16 max of 65535. This means the OC interface MTU leaf cannot faithfully represent what the operating system has configured on a standard interface out of the box.

For reference, IETF ietf-ip (RFC 8344) mirrors the same IPv4 uint16 / IPv6 uint32 split but does not model a configurable link-level MTU on the interface itself in ietf-interfaces (RFC 8343) so the parent/child type conflict is not present there in the same way.

The arguably correct fix would be to widen the interface/subinterface MTU and IPv4 MTU to uint32 to be consistent with the IPv6 MTU leaf and what operating systems actually implement. However, this is a backwards incompatible change to leaves that have been published for a long time and are widely consumed. Implementations and controllers have been built around uint16 expectations for these nodes so the cost of such a change and likelihood of acceptance is understood to be low.

Raising this issue for discussion. If types cannot change then expectations need to be set for when any interface exceeds uint16 boundaries. If pure state (as is the case in many virtual/logical interface scenarios across implementations), then omission from returning such nodes could be an option though reduces visibility and correctness.

History: There was a prior attempt at addressing this via #972 that was marked for discussion then closed/stale

[earies]

Another reference to call out here is the current IETF draft: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-intf-ext-yang-18 which augments the max-frame-size at the interface level as a 32-bit value

https://github.com/YangModels/yang/blob/main/experimental/ietf-extracted-YANG-modules/ietf-if-extensions%402025-01-27.yang#L411-L431

    /*
     * Allows the maximum frame size to be configured or reported.
     */
    leaf max-frame-size {
      if-feature "max-frame-size";
      type uint32 {
        range "64 .. max";
      }
      description
        "The maximum size of layer 2 frames that may be transmitted
         or received on the interface (including any frame header,
         maximum frame payload size, and frame checksum sequence).

         If configured, the max-frame-size also limits the maximum
         frame size of any child sub-interfaces.  The MTU available
         to higher layer protocols is restricted to the maximum frame
         payload size, and MAY be further restricted by explicit
         layer 3 or protocol specific MTU configuration.";

      reference "RFC XXXX, Section 2.5 Maximum Frame Size";
    }

cc: @rgwilton