Ladislav Lhotka <[email protected]> wrote: > Martin Bjorklund <[email protected]> writes: > > > Robert Wilton <[email protected]> wrote: > >> 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? > > > > I think that this is good idea. We have discussed adding properties > > Yes. Such use cases were actually the motivation for introducing > multiple inheritance of identities in the first place. > > > as identities before. Having them in the iana-if-types would make > > these types more useful. > > > > But this would require a non-signinficant change to > > draft-ietf-netmod-intf-ext-yang, right? We would need an update to > > iana-if-types and move the identities there. > > But then iana-if-type would diverge from the underlying IANA > registry, which would be confusing. It is IMO better to start a new > module (or a few of them) with a sound structure of interface types and > no reference to the IANA interface registry.
I don't think it would diverge - all interface types would be there, but some have additional properies (which are not visible in the MIB). But the underlying registry somehow needs to be extended. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
