Tunnel/routed-vlan interface structures and design divergence implications

[earies]

Per OpenConfig community agenda for 2023-01-05

Currently, openconfig-interfaces presents 2 design patterns from a hierarchical perspective in relation to the existence of where L2 and L3 containers and attributes exist.

The primary design pattern is that for most interfaces, there is a hierarchy of interface->subinterface - L2 related attributes are generally covered at the interface while L3 related at the subinterface levels.

module: openconfig-interfaces
  +--rw interfaces
     +--rw interface* [name]
        +--rw subinterfaces
           +--rw subinterface* [index]
              +--rw oc-ip:ipv4
                 +--rw oc-ip:addresses
                 |  +--rw oc-ip:address* [ip]
                 |     +--rw oc-ip:ip        -> ../config/ip
                 |     +--rw oc-ip:config
                 |     |  +--rw oc-ip:ip?              oc-inet:ipv4-address
                 |     |  +--rw oc-ip:prefix-length?   uint8
                 |     +--ro oc-ip:state
                 |     |  +--ro oc-ip:ip?              oc-inet:ipv4-address
                 |     |  +--ro oc-ip:prefix-length?   uint8
                 |     |  +--ro oc-ip:origin?          ip-address-origin
                 ...

It is also worth noting that various other models have a concept to reference back to this concept breaking apart references to the interface + subinterface pair.

e.g.

module: openconfig-network-instance
  +--rw network-instances
     +--rw network-instance* [name]
        +--rw interfaces
           +--rw interface* [id]
              +--rw id        -> ../config/id
              +--rw config
              |  +--rw id?                            string
              |  +--rw interface?                     -> /oc-if:interfaces/interface/name
              |  +--rw subinterface?                  -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/index

However for routed-vlan and tunnel interfaces, the design pattern changes where there is no concept of "subinterfaces". All attributes sit at the root of an interface.

e.g. routed-vlan interface

module: openconfig-interfaces
  +--rw interfaces
     +--rw interface* [name]
        +--rw oc-vlan:routed-vlan
           +--rw oc-ip:ipv4
              +--rw oc-ip:addresses
              |  +--rw oc-ip:address* [ip]
              |     +--rw oc-ip:ip        -> ../config/ip
              |     +--rw oc-ip:config
              |     |  +--rw oc-ip:ip?              oc-inet:ipv4-address
              |     |  +--rw oc-ip:prefix-length?   uint8
              |     +--ro oc-ip:state
              |     |  +--ro oc-ip:ip?              oc-inet:ipv4-address
              |     |  +--ro oc-ip:prefix-length?   uint8
              |     |  +--ro oc-ip:origin?          ip-address-origin
              ...

e.g. tunnel interface

module: openconfig-interfaces
  +--rw interfaces
     +--rw interface* [name]
        +--rw oc-tun:tunnel
           +--rw oc-tun:ipv4
              +--rw oc-tun:addresses
              |  +--rw oc-tun:address* [ip]
              |     +--rw oc-tun:ip        -> ../config/ip
              |     +--rw oc-tun:config
              |     |  +--rw oc-tun:ip?              oc-inet:ipv4-address
              |     |  +--rw oc-tun:prefix-length?   uint8
              |     +--ro oc-tun:state
              |        +--ro oc-tun:ip?              oc-inet:ipv4-address
              |        +--ro oc-tun:prefix-length?   uint8
              |        +--ro oc-tun:origin?          ip-address-origin
              ...

Now only some interfaces have a different design hierarchy. It is not a physical vs. logical split since the normal design pattern also accommodates logical interfaces (e.g. loopbacks)

The schema itself also allows for the full hierarchy in either circumstance since there is no gating by way of YANG language statements. What this really means is that an implementation needs to prevent (cannot deviate effectively) subinterface configuration for the routed-vlan and tunnel variants. In theory the model gives access to configuration of an IP address under both hierarchies for these interfaces.

Effectively we have inconsistent hybrid design patterns likely being driven by separate implementations at some point in time. What this creates is then a proprietary encoding scheme that some implementations need to come up w/ for interface names (e.g. concatenating interface.subinterface) for portions of the model which obviously conflict with the true underlying representation and thus difficulties when referencing from other domains (native schema), logs, CLI, etc..

Impact on path targeting

For any API operations that target a specific path for interesting data (e.g. Give me all interfaces with IPv4 or IPv6 addresses), the divergence in model design for only some interfaces means that a client cannot target a single specific path

e.g.

/interfaces/interface[name=*]/subinterfaces/subinterface/ipv4/addresses

Since the path hierarchy is different, this means a client needs to target multiple paths for consumption or programmability of like objects.