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

[Robert Wilton <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>