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

[Martin Bjorklund <[e-mail]>]

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
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.


/martin