Add interface name type with regex pattern constraint

[dplore]

Change Scope

• This proposes a typedef for a fully qualified interface name with a specific pattern of the name followed by a subinterface index.
• It's imagined that this would be used for interface-refs where it is necessary to point to a fully specified interfaces and subinterface.

See also #573 for content on naming of subinterfaces.

See also #802 which clarifies the use of interface-id

See also openconfig/featureprofiles#2853 for a test referencing the value of the interface-id field.

[OpenConfigBot]

No major YANG version changes in commit 8c74cff

[LimeHat]

It's imagined that this would be used for interface-refs where it is necessary to point to a fully specified interfaces and subinterface.

I think interface-refs already have a strict definition. Am I missing something?

public/release/models/interfaces/openconfig-interfaces.yang

Lines 181 to 207 in 0ae6953

	grouping interface-ref-common {
	description
	"Reference leafrefs to interface / subinterface";
	leaf interface {
	type leafref {
	path "/oc-if:interfaces/oc-if:interface/oc-if:name";
	}
	description
	"Reference to a base interface. If a reference to a
	subinterface is required, this leaf must be specified
	to indicate the base interface.";
	}
	leaf subinterface {
	type leafref {
	path "/oc-if:interfaces/" +
	"oc-if:interface[oc-if:name=current()/../interface]/" +
	"oc-if:subinterfaces/oc-if:subinterface/oc-if:index";
	}
	description
	"Reference to a subinterface -- this requires the base
	interface to be specified using the interface leaf in
	this container. If only a reference to a base interface
	is requuired, this leaf should not be set.";
	}
	}

[dplore]

I've updated the regex and description to show the suffix representing subinterface as optional.

This was discussed in the 2024-04-16 OC operators meeting.

It is observed that interface names are a very long standing area with a loose specification by design to allow for varied implementations, especially when it comes to media, hardware hierarchy and human readable names. There is some concern that we should understand what operational problems we are making better and weigh this against the cost of any change which is widespread in the models. Comments about the problem we are solving, particularly in a network operational context are needed to move this forward.

[earies]

For the most part I think we are probably ok on common "system-defined" physical/logical/virtual interface naming across network vendor implementations but this excludes any interface name that may carry a . unless the interface has no subinterface and encodes an integer post a single . (which is also legal linux netdev naming)

$ cat interfaces.txt 
et-0/0/0
et-0/0/0.0
et-0/0/0.1024
et-0/0/0:0.0
et-0/0/0:0.1024
ae0
ae0.0
ae0_0
TenGigabitEthernet0/0/0
TenGigabitEthernet0/0/0.0
mgmt0
mgmt0.0
Foo Bar Car
Foo Bar Car.1024
Foo Bar Car.1024.10
Foo/Bar/Car
Foo/Bar/Car:0
Foo/Bar/Car:0.100
Foo.Bar.Car/Jar
Foo.Bar.Car/Jar.100
Foo.Bar.Car/Jar.100
10/1/12
foo.1.2.3
foo.bar:0
foo.bar:0.0

$ cat interfaces.txt  | grep -vE "^([^.]+)(\.[0-9]+)?$" 
Foo Bar Car.1024.10
Foo.Bar.Car/Jar
Foo.Bar.Car/Jar.100
Foo.Bar.Car/Jar.100
foo.1.2.3
foo.bar:0
foo.bar:0.0

Maybe less of an issue for system-defined names but user-defined names (think virtual tunnels, etc..) now put a constraint on what the user can name an interface

[dplore]

To entertain this idea a bit more, a robust way to be very permissive on interface names could be to replace the single string interface-id with a strongly typed model representation with two leafs:

1. interface-name type string
2. Optional, sub-interface-index type uint32

Thinking a bit about how to model this in yang, we could add/replace each leaf which uses the interface-id type with the above two leaves. Today typedef interface-id is present in 17 leafs which at a glance all relate some configuration to an interface.

I am not sure it's worth the churn in the model to make a change like this and would like to hear what the issues are.

[LimeHat]

Is there a problem with subinterface references that was not solved in #802 ?

[earies]

Am a bit confused - it seems what you are proposing is not much different than the interface-ref-common grouping:

https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-interfaces.yang#L209-L235

But the problem trying to be solved here was the fact that we have a single leaf node key used in a list somewhere that is either completely user-defined (made up objects that can differ all over each use) or we use a typedef with some set of rules behind it to drive consistency in the list key naming per implementation.

Those "rules" are either gated by a pattern (which is likely too restrictive or too loose) or a very descriptive description stmt on an YANG unbounded string.

Now, this could be combined into the above grouping so that a common grouping of a list and child nodes (the ultimate distinct leafrefs) can be used and reapplied but this is primarily about ensuring that a key used to reference back to an interface (or subinterface combo) is consistent across all usage in each domain.

It's not about consistency across implementations but a set of rules within the same implementation at least.

[cfyo]

Do you have examples of unqualified interface names that you are trying to avoid by doing this?

[dplore]

I'll close this PR as I don't have an example of implementations of interface leaf references which are causing a problem. If the community identifies this, we can reopen.