Re: [netmod] YANG doctor review of draft-ietf-netmod-intf-ext-yang-04

[Ladislav Lhotka <[e-mail]>]

Martin Bjorklund <[e-mail]> writes:

> Robert Wilton <[e-mail]> 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.

Lada

>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67