Subject: [netmod] New version of draft-wilton-netmod-intf-ext-yang-01

From: Robert Wilton <[email-masked]>
Date: Mon, 26 Oct 2015 15:50:01 +0000

Hi,

Last week I posted slightly revised version of both 
draft-wilton-netmod-intf-ext-yang-01 and 
draft-wilton-netmod-intf-vlan-yang-01.  Any feedback on any of the 
models contained within these two drafts is very welcome, but I would be 
particularly interested in any opinions regarding some slight changes 
for modelling sub-interfaces in the interfaces-extensions draft.

The main changes that I've made to intf-ext-yang-01 are:

1) I've defined a new "sub-interface" identity to represent the 
behaviour of any interface type that is a representation of a 
sub-interface.  The idea here is to ensure that the common sub-interface 
configuration leaves can be re-used by any other sub-interface types 
that are defined in future models, or possibly vendor specific interface 
types. E.g. the augmentation that adds sub-interface related 
configuration in interfaces-common.yang:

<yang>
   identity sub-interface {
     description "Base type for generic sub-interfaces.  New or custom
                  interface types can derive from this type to
                  inherit generic sub-interface configuration";
   }

   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'"  {
       description
         "Any ianaift:types that explicitly represent sub-interfaces
          or any types that derive from the sub-interface identity";
     }

     ... sub-interface specific configuration nodes go here.
   }
</yang>

If this is accepted as generally a good approach of modelling this in a 
future safe manner, then I was considering also defining an interface 
type that is the common representation of a physical- interfaces for 
some of the other features defined in the interface-extension draft.

2) I've defined a new ethSubInterface identity in interface-common.yang 
that inherits from ianaift:l2vlan and the new sub-interface identity above.
  - Using Yang 1.1 this will allow the augmentation of the 
parent-interface leaf to be marked as mandatory.
  - It also solves a possible concern that some vendors may have a 
different interpretation of what the IANA interface type "l2vlan" 
actually means (noting that the IANA only provides a slightly vague 
definition).

I.e.
<yang>
   identity ethSubInterface{
     base ianaift:l2vlan;
     base sub-interface;

     description "Sub-interface of any interface types that uses
                  Ethernet framing (with or without 802.1Q tagging)";
   }
</yang>

3) The features above mean that module is marked a being Yang version 
1.1 only.

Any feedback is appreciated.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Oct 2015 14:25:52 +0100

Hi Rob,

I think both modules are useful extensions to ietf-interfaces, and I
would support adopting it as a NETMOD work item. I have a few
comments/questions:

   1. You are using several YANG 1.1 features (multiple identityref
      bases, mandatory nodes in augments), so you should have 6020bis
      as a normative reference rather than RFC 6020.

   2. "when" expressions in the module "interfaces-ethernet-like"
      demonstrate that IANA interface types are pretty much
      useless. Not only is it necessary to list all ethernet-like
      interface types one by one, but it also isn't extensible: these
      augments won't apply to new ethernet-like types.

      Moreover - and this might actually be a flaw in 6020bis - it is
      not allowed to update the "when" statements in a new revision of
      the module.

      Anyway, I think it is necessary to have an "Ethernet" identity
      from which all ethernet-like interface types would be derived.
      The "when" expressions would then be simple and extensible:

        when "derived-from(if:type, 'ietf-ethernet', 'Ethernet')";

   3. How is "l2-mtu" related to L3 MTU (under "ip:ipv[46])? What
      about

        must "not(l2-mtu <= ip:ipv4/ip:mtu)";

      and similarly for IPv6?

   4. I think the name "transport-layer" isn't appropriate for an
      enumeration "layer-1"/"layer-2"/"layer-3" because "Transport
      Layer" is the name for "layer-4" in the ISO OSI model. 

Lada

Robert Wilton <[email-masked]> writes:

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

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

---

From: Robert Wilton <[email-masked]>
Date: Tue, 27 Oct 2015 15:12:09 +0000

Hi Lada,

Thanks for the review and comments, please see inline ...

>        as a normative reference rather than RFC 6020.
Yes, I'll fix this.

>        augments won't apply to new ethernet-like types.
Yes, I agree.

The other concern that I have with the IANA interface types is that I 
feel that their importance has changed somewhat.

In the past, it feels like the IANA interface type was just a label to 
attach to an interface to help the operator understand what type of 
interface is was, e.g. a bit like a description.  As such, I think that 
historically vendors may interpret the meaning of the interface types 
somewhat differently and it didn't really matter very much.

However, with YANG, the IANA interface type identities are being used in 
a more fundamental way to define which parts of the data model are 
available and meaningful.  For this to be sane, I think that the 
definitions might need to be clarified or strengthened, and personally I 
wonder whether the list could sensibly be cut down in size.  There are 
280 IANA interface types defined, but I suspect that less than half of 
those are still in common usage.  E.g. in Cisco's IOS XR, I think that I 
only counted 20 that are actually in use.

>          when "derived-from(if:type, 'ietf-ethernet', 'Ethernet')";
Yes, I agree.

I think that it would be useful to define a set of base identities that 
describe the common semantics of interfaces.  E.g. Etherlike, Physical, 
Sub-interface, Aggregate-interface, Optical, Tunnel, etc.

The question is what do we do with the existing IANA types, it would be 
useful if they also inherited from the appropriate base identities 
rather than be carried around as special cases.  Perhaps there is an 
argument for defining a new set of YANG interface identifiers:

E.g.

iana-if-type.yang defines
   identity ethernetCsmacd {
     base iana-interface-type;
     description
       "For all Ethernet-like interfaces, regardless of speed,
        as per RFC 3635.";
     reference
       "RFC 3635 - Definitions of Managed Objects for the
                   Ethernet-like Interface Types";
   }

New base identities could be defined like:

   identity physical {
     description "Base type for physical interfaces";
   }

   identity sub-interface {

   identity ethernet-like {
     description "Base type for any interfaces that use Ethernet framing at OSI layer 2";
   }

New interface identities could also be defined like:

   identity ethernet {
     base ianaift:ethernetCsmacd;
     base physical;
     base ethernet-like;

     description "Physical Ethernet interface";
  }

     base ethernet-like;

Ethernet physical interface configuration would use: 
derived-from(if:type, 'ietf-ethernet', 'Ethernet')
Etherlike configuration (e.g. MAC address) would use: 
derived-from(if:type, ..., 'ethernet-like')
Common physical interface configuration would use: derived-from(if:type, 
..., 'physical')
Etc.

>          must "not(l2-mtu <= ip:ipv4/ip:mtu)";
Yes, I agree, although possibly the definitions might be cleaner in the 
ip:ipv4 and ipv6 modules.  I.e. it is better if the higher layers 
reference the lower layers rather than the other way round.

The meaning (and hence name) of the l2-mtu leaf probably needs some more 
refinement.  Basically, I think that we want to have a tight MTU 
definition that always includes any and all appropriate layer 2 
overheads.  Specifically I want to avoid cases were MTUs are sometimes 
defined in terms of the layer 3 payload which then don't play nicely 
with layer 2 services.  But conversely the definition should also work 
for a pure layer 3 service interface that doesn't have any applicable 
layer 2 overheads.

>        Layer" is the name for "layer-4" in the ISO OSI model.
Yes, I think that you are right.  We need to come up with a better name 
here.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Oct 2015 16:29:18 +0100

> somewhat differently and it didn't really matter very much.

IANA interface types are actually a bit more than just a label since
there are several interface type specific MIB modules that are
registered in the transmission OID branch and the registration number
usually matches the interface type number in the IANA registry. But
yes, for monitoring, a broad classification is usually sufficient.
For configuration, one likes to have more details but then our
understanding of interfaces has evolved a lot over the years (and
producing a new interface classification model that can sustain
another 30+ years is likely tricky).

/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: Tue, 27 Oct 2015 16:33:08 +0100

> On 27 Oct 2015, at 16:12, Robert Wilton <[email-masked]> wrote:
> 
> Hi Lada,
> 
> The other concern that I have with the IANA interface types is that I feel that their importance has changed somewhat.
> 
> In the past, it feels like the IANA interface type was just a label to attach to an interface to help the operator understand what type of interface is was, e.g. a bit like a description.  As such, I think that historically vendors may interpret the meaning of the interface types somewhat differently and it didn't really matter very much.
> 
> However, with YANG, the IANA interface type identities are being used in a more fundamental way to define which parts of the data model are available and meaningful.  For this to be sane, I think that the definitions might need to be clarified or strengthened, and personally I wonder whether the list could sensibly be cut down in size.  There are 280 IANA interface types defined, but I suspect that less than half of those are still in common usage.  E.g. in Cisco's IOS XR, I think that I only counted 20 that are actually in use.

Absolutely. The IANA interface type registry is a mess with many obsolete or weird items, but on the other hand some important types are either missing or comprised in a very general type. 

> I think that it would be useful to define a set of base identities that describe the common semantics of interfaces.  E.g. Etherlike, Physical, Sub-interface, Aggregate-interface, Optical, Tunnel, etc.

Agreed.

> 
> The question is what do we do with the existing IANA types, it would be useful if they also inherited from the appropriate base identities rather than be carried around as special cases.  Perhaps there is an argument for defining a new set of YANG interface identifiers:
> 
> E.g.
> 

In principle, this IANA identity could be used as a base for all ethernet-like interfaces, although I don't like the name (invariably make a typo in it:-).

> Ethernet physical interface configuration would use: derived-from(if:type, 'ietf-ethernet', 'Ethernet')
> Etherlike configuration (e.g. MAC address) would use: derived-from(if:type, ..., 'ethernet-like')
> Common physical interface configuration would use: derived-from(if:type, ..., 'physical')
> Etc.
> 
>> 
> Yes, I agree, although possibly the definitions might be cleaner in the ip:ipv4 and ipv6 modules.  I.e. it is better if the higher layers reference the lower layers rather than the other way round.
> 
> The meaning (and hence name) of the l2-mtu leaf probably needs some more refinement.  Basically, I think that we want to have a tight MTU definition that always includes any and all appropriate layer 2 overheads.  Specifically I want to avoid cases were MTUs are sometimes defined in terms of the layer 3 payload which then don't play nicely with layer 2 services.  But conversely the definition should also work for a pure layer 3 service interface that doesn't have any applicable layer 2 overheads.

I think ietf-interfaces initially included L2 mtu but then it was decided not to use it. I don't remember exactly what the reason was, perhaps that the concept of MTU differs among L2 interface types.

Lada 

> Yes, I think that you are right.  We need to come up with a better name here.
> 
> Thanks,
> Rob
> 
>> 
>> Lada
>>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 27 Oct 2015 16:34:10 +0000

> In principle, this IANA identity could be used as a base for all ethernet-like interfaces, although I don't like the name (invariably make a typo in it:-).
I think that we need to be able to differentiate between interfaces that 
are physical Ethernet interfaces (such as 1GE, 10GE, 40GE, which are all 
defined by IANA as ethernetCsmacd) vs interfaces that have Ethernet 
framing but are not physical Ethernet interfaces (e.g. a LAG aggregated 
interface, Ethernet sub-interfaces, L3 interface on an VLAN bridge, 
pseudo-wire terminated to L3, etc).

Configuration such as speed/duplex/auto-negotiation is only applicable 
to physical Ethernet interfaces, where as a MAC address is associated 
with all Ethernet-like interfaces.

> I think ietf-interfaces initially included L2 mtu but then it was decided not to use it. I don't remember exactly what the reason was, perhaps that the concept of MTU differs among L2 interface typ…
An alternative choice is to have a separate mtu leaf defined for each 
interface type, but I would expect that this would be annoying for 
clients because they would need to look up the interface type to be able 
to program the MTU (since the mtu leaves would end up in different 
module namespaces)

So I hope that we can come up with a universal definition across all L2 
interface types.  Certainly the OS that I work on has a well defined MTU 
definition that works across all L2 interfaces.

Thanks,
Rob

> .

---

From: Robert Wilton <[email-masked]>
Date: Tue, 27 Oct 2015 16:53:22 +0000

> another 30+ years is likely tricky).
Yes, the problem that I'm trying to solve is that I'm trying to define 
common configuration that spans across multiple interface types (to 
avoid having per interface type configuration in separate modules, so 
that even if they have the same leaf names they would be in different 
module namespaces).

One choice is to just make the configuration available on all interface 
types, but this somewhat pollutes the global YANG structure , and I 
think that it makes the data model harder to use because the client 
can't necessary determine which configuration leaves are really valid.

The alternative choice is to restrict the configuration down to the set 
of interface types that it applies to.  However, the problem here is 
that it is hard to find the correct set of interface types (out of the 
260 that available) to restrict it to.  Especially since quite a few of 
the IANA interface types are vendor specific, and probably meaningless 
to everyone else.

Other than breaking with convention, I can see a clear benefit if all 
new vendor specific interface types were defined in the module that 
defines the associated new interface type specific configuration for 
them rather than being added to the centralized IANA list.

But I also see benefit in having a cleaner way to reference the existing 
interface types in a way that is easy to understand and extensible.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Oct 2015 12:37:52 +0100 (CET)

Hi,

>       not allowed to update the "when" statements in a new revision of

I think this text should be added to the update rules:

  o  A "when" statement may be removed or its constraint relaxed.

(compare w/ "must")

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 31 Oct 2015 14:03:47 +0900

> On 30 Oct 2015, at 20:37, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

Agreed.

Lada