Add interfaces layer property to openconfig-interfaces model #1083
Conversation
|
/gcbrun |
|
No major YANG version changes in commit 709071e |
|
/gcbrun |
| description | ||
| "Types associated with a interface"; | ||
|
|
||
| oc-ext:openconfig-version "3.7.1"; |
There was a problem hiding this comment.
Since this is not a submodule, we can start with 1.0.0
|
Thanks Mike, please provide some explicit examples where there is a problem without this leaf and using the new leaf solves the issue. Consider that subinterfaces is where OC defines properties for logical and layer 3 interfaces. |
Here is the additional information: Problem Statement: Take an ethernet port ‘eth1/1’ as example.
The trunk config is equivalent to the below opeconfig path.
The ip/ipv6 config is equivalent to the below opeconfig path. Now, for an openconfig user, the existing ‘name=eth1/3” and “type=ethernetCsmacd” could not differentiate the interface layer,so user cannot change the L2-ish / L3-ish freely. There exist two current workarounds:
These two workaround are far less than ideal for the usability perspective. Subinterfaces This proposed “layer” property does NOT change sub-interfaces behavior. Take the same ethernet 1/3 as the example. The equivalent openconfig representation is as the following. If e1/3 is in the L2 layer, then sub-interfaces is not even supported. Granted that for other vendor devices, they may support sub-interfaces under both physical L2 and L3 parent interfaces. list interface {
...
uses subinterfaces-top {
+++ when "oc-if:config/oc-if:layer = 'oc-if-type:L3'" {
...
}
} |
Note that in OC, IP addresses always belong to subinterfaces (which is not the case in this cli example).
In a specific implementation, perhaps. In OC, subinterfaces can be used with L2 network instances. I understand that the idea is to introduce "switchport/no switchport" equivalent to OC, but I'm not convinced it fits well into the overall architecture. There's a bit more basis for that for legacy-ish l2 switching that does not use subifs, but then there's already public/release/models/vlan/openconfig-vlan.yang Lines 177 to 182 in 4f40878 @robshakir any thoughts? |
|
I agree with @LimeHat with all his comments. Another question would be: if an implementation needs this, can the interface |
|
A few comments:
Not entirely true - see: #781
Any new model that has been introduced to date should have carried
Agreed - how many implementations do you have to dictate an ethernet interface to be ethernet? Then validate to ensure the dictated type actually corresponds to the actual underlying physical hardware? Or drop on the floor, do nothing with it but merely reflect it back... For logical interfaces where you can dictate various encapsulations sure - also see: #780 As an implementor (and cross referencing other implementations), this
Not necessarily however this is also not a unique problem when translating between alien schemas and native constructs that mismatch in implementation behavior. Translation logic could handle this but it comes at a cost - this is what happens when trying to normalize things that may vary greatly underneath - the 1:many and many:1 translation w/ additional checks then occurs which is derived off the intended payload. Part of this is also that the model does not provide some of the guardrails in that a client can generate a schema compliant configuration that would ultimately fail on the device when applied. This again is a common problem statement in all of this which also applies to the underlying native implementation as well.
And seems along the same lines as classical We (Juniper) don't have this explicit concept but rather take paths based on "families" - essentially no precursor step necessary to dictate the mode |
|
Hi there, I am not seeing an operational use case for this change. Can you provide some specific examples of configuration that is needed operationally and cannot be done without this change? The two examples seem relatively straight forward for the NOS to understand if layer 2 switching or layer 3 routing is requested by the user: The NOS should enforce that the interface in question cannot be configured with both of these snippets at the same time. |
Change Scope
The proposal is to add an additional "layer" leaf to interface
This is to explicitly specify the interface layer.
When the 'layer" is not specified, the behavior is the same as if the "layer" is not defined in the previous model.
pyang tree output
Rationale
Currently in openconfig-interface, there is no “layer” information for an interface,
while L2 (switching) / L3 (routing) child configs are all mixed across the interface model.
Since the interface can mix and match both L2 and L3 config, the model user could have the impression that any given interface can operate concurrently in both the switching and routing mode. This is not true across vendors. Commonly an interface either operates in L2 or L3 mode, and it requires explicit configuration to toggle the interface layer.
The lack of the “layer” affects both the model user and the target device :
Currently the model user would need to infer the interface layer.
Via the interface "name"
The interface name may suggest its operating layer.
For example, when the interface name is like vl12, Vlan12, lo100,
the user can infer these interfaces are logical, and thus are used for routing.
But such naming semantics is rather vendor specific
Via the interface "type"
Some specific interface types could also suggest its operarting layer.
For example, the type "iana:softwareLoopback" is a lookback, and thus deemed for routing.
Though commonly, the interface type refers more to the underlying medium/technology.
For example, the type "iana:ethernetCsmacd" only means the inteface is an ethernet link,
it does not tell whether such ethernet interface serves for switching or routing.
Oppositely, the target device also needs to infer the model user’s intent.
Take the above ethernet interface as example. The interface may support either L2 or L3 functionality.
. If the user ever touches the L3-ish config, like ip (or dhcp, etc), then toggle the interface to L3
. If the user ever touches the L2-ish config, like vlan (or dot1q, etc), then toggle the interface to L2.
These guess works are not straight-forward nor unreliable.
Thus the proposal is to add a new config leaf “interfaces/interface/config/layer” to eliminate such uncertainty/ambiguity.
Though to emphasize again, the new "layer" config is optional. If the "layer" is not specified, the behavior remains the same as the current behavior.
Platform Implementations