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

[Martin Bjorklund <[e-mail]>]

Ladislav Lhotka <[e-mail]> wrote:
> 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.

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