Subject: [netmod] draft-wilton-netmod-interface-properties-00

From: Robert Wilton <[email-masked]>
Date: Mon, 17 Jul 2017 14:06:37 +0200

Hi,

In the NETMOD session on Wednesday I will spend 5 minutes speaking on 
draft-wilton-netmod-interface-properties-00, that has been created due 
to discussions with various folks to handle interface type specific 
configuration.

The draft isn't particularly long, 21 pages, two thirds of that is just 
examples, and it is presenting a simple idea.

In particular, it is aiming at solving the problem of when statements 
like this:

      augment "/if:interfaces/if:interface" {
        when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or
              derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or
              derived-from-or-self(if:type, 'ianaift:l2vlan') or
              derived-from-or-self(if:type, 'ianaift:ifPwType')" {
          description "Applies to all Ethernet-like interfaces";
        }

and instead proposes this:

     augment "/if:interfaces/if:interface" {
       when "derived-from(if:type, 'ianaifp:ethernet-like')" {
         description
           "Applies to all interfaces that derive from the Ethernet-like
            interface property.";
       }

The core idea being that new identities are defined to represent 
interface properties (like ethernet-like) and the existing interface 
types iana-if-types.yang are updated to also derive from the new 
interface properties.

This simplifies the YANG, should make interface based configuration more 
future proof, since new interface types can also derive from the 
appropriate interface properties.  Of course additional interface 
properties could also be defined.

I'm seeking input from the WG as to whether they like this approach, AND 
also whether the WG drafts: draft-ietf-netmod-intf-ext-yang-05 and 
draft-ietf-netmod-sub-intf-vlan-model-02 should be updated to make use 
of this approach (possibly in a future bis revision to avoid delaying 
publishing the models).

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Jul 2017 11:27:13 +0200

Hi Rob,

I think this is a very useful work and we will probably implement it
soon. A few comments:

- I support the proposed redesign of "iana-if-type" but I believe this
  module should in fact be declared historic. For one, the name of the
  most frequently used type, "ethernetCsmacd", is not only notoriously
  hard to remember but it is also a misnomer: these days, almost no
  Ethernet network uses CSMA/CD any more. Instead, "csma-cd" can be
  another identity that could be added to the mix of bases where
  necessary.

- Interface type identities should be defined in a distributed way and
  not in a single module as in "iana-if-type". A module defining
  configuration and state data for a particular technology should also
  define the corresponding identity or identities. This way, the choice
  of interface types will always be limited to those supported by a
  specific server.

- In Appendix B I don't understand the comment in the definition of
  container "encapsulation": what could be the abstract type and how
  would it aid extensibility?

Thanks, Lada

Robert Wilton <[email-masked]> writes:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Alex Campbell <[email-masked]>
Date: Wed, 26 Jul 2017 23:17:16 +0000

Hi,

I would very much like to see this happen.

However I recommend at least splitting up "ethernet-like" into "ethernet-mac-like" and "ethernet-phy-like". At Aviat we have microwave radio interfaces that behave like Ethernet at the MAC level but have totally different PHYs. The distinction is also useful for virtual links, such as link aggregations and tunnels.

________________________________________
From: netmod <[email-masked]> on behalf of Ladislav Lhotka <[email-masked]>
Sent: Wednesday, 26 July 2017 9:27 p.m.
To: Robert Wilton; [email-masked]
Subject: Re: [netmod] draft-wilton-netmod-interface-properties-00

Hi Rob,

Thanks, Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jul 2017 09:31:43 +0200

Hi,

what is needed is a clear and crisp description what terms such as
"ethernet-like", "ethernet-mac-like", "ethernet-phy-like" really mean.
Ideally, proposals for terms would include such descriptions, perhaps
including examples where these terms apply and where they do not
apply. The devil is in the details.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Jul 2017 11:12:50 +0200

> On 27 Jul 2017, at 09:31, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Hi,
> 

Even better, these identities could be defined along with the corresponding configuration and state data. From the viewpoint of data modelling, everything would then be absolutely clear.

Lada