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

[Ladislav Lhotka <[e-mail]>]

> On 11 Apr 2017, at 13:31, Martin Bjorklund <[e-mail]> wrote:
> 
> 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.

The IANA registry is mostly rubbish - quite fundamental interface types are missing but, on the other hand, obsolete/experimental/humorous types are there. The plethora of Ethernet types is represented by a single entry (moreover with a totally impossible name).

Lada

> 
> 
> /martin

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