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

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Apr 2017 10:43:23 -0700

Overall:

The document is well-written and almost ready for publication

Comments:

1) No examples or guidance for "encaps-type"

The document does not really define the standards value
for this empty choice.  There are no examples showing its use.
More work is needed for this part of the module.

The following TODO needs to be resolved and the note removed
from the document:

           /*
            * TODO - Should we introduce an abstract type to make this
            *        extensible to new interface types, or vendor
            *        specific interface types?
            */

2) normative overlap

The text and layout of sec. 3 is good.
The issue is that the YANG module text copies from this section
in some places (leafs) and references it in others (feature definitions)

Some parts like "half-life" are more detailed in the leaf definition
than the plain text in sec. 3

Perhaps the leaf definitions can have reference-stmts added
as needed, so it is clear that the YANG leaf is not the
entire normative text.  The YANG descriptions are good,
but maybe not complete wrt/ sec. 3 additional text.

sec 3.7 typo:

the existing the sub-interface
                    ^^^  remove extra 'the'

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)

Andy

---

From: Vladimir Vassilev <[email-masked]>
Date: Mon, 10 Apr 2017 18:19:52 +0200

Hello,

> (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'"  {

Vladimir

---

From: Robert Wilton <[email-masked]>
Date: Mon, 10 Apr 2017 18:16:52 +0100

Hi Vladimir, all,

On 10/04/2017 17:19, Vladimir Vassilev wrote:
> 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:
>

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Apr 2017 12:13:13 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> identity.  I don't think that this idea just applies to
> sub-interfaces, but other interface properties as well.  E.g.
>  ethernet-like (i.e. does the interface use ethernet framing).
>  E.g. this would apply to physical Ethernet, LAG, IRB interfaces.
> 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.
> 
> Then, for example, the IANA type for atm & l2vlan (if this is the IANA
> type for an Ethernet sub-interface) would change from:
> 
> 
> 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.
> 

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Apr 2017 13:26:40 +0200

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

> 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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Apr 2017 13:31:33 +0200 (CEST)

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Apr 2017 13:56:03 +0200

> On 11 Apr 2017, at 13:31, Martin Bjorklund <[email-masked]> wrote:
> 

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