Hi Vladimir, all,
On 10/04/2017 17:19, Vladimir Vassilev wrote:
Hello,
On 04/06/2017 07:43 PM, Andy Bierman wrote:
3) identity ethSubInterface
This identity is used in the encapsulation container when-stmt.
It is not clear if this is intended as a base identity (like identity
sub-interface)
An example for the encapsulation container would help clarify the
expected usage
This also has 2 bases (sub-interface and l2vlan).
Some explanation in the identity-stmt would be helpful
(since this is a new YANG 1.1 construct)
It seems the intentended result was identity similar to
ianaift:atmSubInterface (thus the naming convention change
ethSubInterface instead of eth-sub-interface). I think it is less
confusing to name the identity with the same naming convention used
for the rest of the identities introduced e.g. sub-interface,
loopback-internal etc. and if needed define new atm-sub-interface
based on sub-interface. I am not sure even atm users would like a
model where atmSubInterface will be the only identity of all future
sub interface based identities not being derived from sub-interface
because of this precedent:
augment "/if:interfaces/if:interface" {
when "derived-from(if:type,
'ietf-if-cmn',
'sub-interface') or
if:type = 'ianaift:atmSubInterface' or
if:type = 'ianaift:frameRelay'" {
My idea was that all sub-interfaces could inherit from a common
identity. I don't think that this idea just applies to sub-interfaces,
but other interface properties as well. E.g.
sub-interface (i.e. any interface that is logically a child interface
of some parent interface, e.g. Ethernet/VLAN sub-interface, ATM
sub-interface, FR sub-interface)
ethernet-like (i.e. does the interface use ethernet framing). E.g.
this would apply to physical Ethernet, LAG, IRB interfaces.
physical (i.e. an interface that is generally instantiated due to some
physical hardware)
logical? (This is harder to define, but roughly an interface that is a
software construct).
there must be other generic properties as well.
My main aim is for future flexibility. I.e. so that if need interface
types get defined in the future they can share existing interface
related configuration and state without having to redefine it.
Similarly, if there are vendor specific variants of interfaces then they
could also reuse the existing interface related configuration and state
without having to define vendor specific MTU leaves, etc for the new
interface type.
My refinement of this idea, is still to define these generic properties,
but then revise iana-if-type.yang to add these common interface
properties as additional base identities.
E.g.
identity interface-property-type {
description
"Base identity from which all interface properties are
derived.";
}
identity sub-interface-like {
description
"The interface has sub-interface properties";
base interface-property-type;
}
identity ethernet-like {
description
"The interface uses ethernet framing, e.g. has a MAC address associated
with it.";
base interface-property-type;
}
...
Then, for example, the IANA type for atm & l2vlan (if this is the IANA type for
an Ethernet sub-interface) would change from:
identity atmSubInterface {
base iana-interface-type;
description
"ATM Sub Interface.";
}
identity l2vlan {
base iana-interface-type;
description
"Layer 2 Virtual LAN using 802.1Q.";
}
to:
identity atmSubInterface {
base iana-interface-type;
base sub-interface-like;
description
"ATM Sub Interface.";
}
identity l2vlan {
base iana-interface-type;
base sub-interface-like;
description
"Layer 2 Virtual LAN using 802.1Q.";
}
and hence the augment can just become:
augment "/if:interfaces/if:interface" {
when "derived-from(if:type, 'ietf-if', 'sub-interface')" {
...
}
If someone wants to define a new type of sub-interface in the future
they can. They just need to ensure that when they define the type in
iana-if-types it also derives from the sub-interface property, and then
they would automatically pick up the generic sub-interface configuration
leaf. This would fix this issue that having when statements on IANA
defined interface types isn't really robust or flexible.
Finally, adding these properties to iana-if-types.yang would be a
backwards compatible change.
What are other peoples opinion's on this idea?
Thanks,
Rob
Vladimir
Andy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
