Add a summary document explaining interface/subinterface differences

[robshakir]

When discussing device implementations for telemetry where a system maintains a "default" subinterface - there have been some different interpretations as to how to map telemetry to the entities that exist there. This document provides some implementation guidance on this matter.

  * (A) doc/reference/interface_subinterface.md
    - Add a document that covers the way that systems that have an
      implied default subinterface should handle telemetry data. This
      addresses an implementation decision discussed with external
      developers.

[OpenConfigBot]

Compatibility Report for commit c280dba:
⛔ yanglint@SO 1.10.17

[robshakir]

ptal, i believe this is now ready for merge.

[dplore]

I found this last part a little difficult to follow. Does this cover the intent? Or is there some case I am missing?

Suggested change

	For systems that have this default mapping of subinterface 0 to a parent
	interface, the configuration of separate IPv4 and IPv6 subinterfaces with no
	specified encapsulations is invalid - since in this case there is ambiguity as
	to which OpenConfig `subinterface` entities map to the "default" subinterface's
	config on the device. (i.e., OpenConfig `subinterface` index 4 and 6 configured
	on `GigabitEthernet42` would potentially both map into configuration and state
	directly under `GigabitEthernet` in the native schema). Conversely, a single
	subinterface that specifies both IPv4 and IPv6 addresses is valid, since this
	unambiguously maps to the "default" subinterface on these systems.
	- When IPv4 and IPv6 are configured on the default interface, both must be
	treated as attached to index 0.

[earies]

I think there should be some coverage of expectations for routed-vlan and tunnel interfaces here as well.

In these situations, the normal subinterface IPv4/IPv6 hierarchies are rooted directly at the interface with no subinterface concepts currently. For implementations that support this still under subinterfaces (e.g. JUNOS), what is the expectation then for interface naming since you have a subinterface index that needs to be accounted for?

The only current solution I see is to concatenate the interface/subinterface into the interface name now for these logical interfaces which diverges protocol from physical interfaces.

Essentially it is the reverse of the problem statement described here where some implementations support direct IP configuration at the base interface level

[robshakir]

This seems a reasonable clarification to make. I can add to this document to cover this.

The concept that was intended here in the design was that logical interfaces that are within the /interfaces hierarchy, we would not allow subdivision of these logical interfaces any further (since there didn't seem to be a case whereby one would operationally want to subdivide such interfaces rather than create a new one).

When you say "diverges protocol from physical interfaces" -- isn't this something that must be true for a logical interface? (i.e., if I have a virtual interface that corresponds to a L3 interface on a VLAN, then this interface might be coupled to multiple physical interfaces, so probably needs to be separate, the same is likely true where we have tunnels that are not associated with physical interfaces.)

[earies]

When you say "diverges protocol from physical interfaces" -- isn't this something that must be true for a logical interface?

Not all - I was just pointing out there are 2 classes of interfaces (routed-vlan (SVI/BVI/IRB/VLAN, etc..) + tunnel) that break from the interface/subinterface concept in the modeling when maybe they shouldn't have. Other logical interfaces, such as a loopback interface in some implementations is represented as just lo (which falls into the category of assuming there is an index 0) or the full loX.Y (e.g. lo0.0, lo0.1, etc..). In the prior lo and lo:0 are actually different interfaces...

Another concern as a side effect due to the divergence of these 2 classes of interfaces from the rest (which other logicals fall into such as loopbacks) is anywhere that references any constructs such as oc-if:interface-ref-common are subject to an incorrect assumption since the construct doesn't exist.

I don't recall the history on this item but is there any reason that routed-vlan and tunnel interfaces just didn't follow the same consistent pattern here where the same protocol could be followed if subinterfaces didn't actually exist (e.g. use index 0 placeholder)?