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.

[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