Subject: [netmod] An abundant amount of IANA if types...

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 5 Apr 2018 08:21:58 +0000

Hi,

We were wondering if it would make sense to introduce features in the IANA if types YANG model to enable grouping of related interface types.  This would allow implementations to include only the types it really requires (by supporting the related features but not the others) and (in case of a CLI interface) would reduce the possible completions if an operator would ask for the possible values of the type of an interface.
Has this ever been considered/discussed?

Best regards,
Bart

---

From: Alex Campbell <[email-masked]>
Date: Thu, 5 Apr 2018 23:59:34 +0000

I haven't seen any previous discussions on the topic, but we have a similar problem.

Note this is not really to do with YANG itself, so much as the practical limitations of the software package that provides our CLI interface.

In NETCONF, the existence of extra unused identities doesn't pose any problem.

________________________________
From: netmod <[email-masked]> on behalf of Bogaert, Bart (Nokia - BE/Antwerp) <[email-masked]>
Sent: Thursday, 5 April 2018 8:21 p.m.
To: [email-masked]
Subject: [netmod] An abundant amount of IANA if types...

Hi,

Best regards,
Bart

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Apr 2018 09:55:14 +0200

Hi,

I have argued several times in the past that the IANA interface list (and, for
that matter, the iana-if-type module) is a useless pile of rubbish because

- for some interface classes (Ethernet, tunnels) it is way too coarse-grained

- on the other hand, it contains a lot of stuff that nobody will ever use

- using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet
is outright stupid

- YANG identities allow for encoding important relationships in interface types,in the flat list all this information is lost 

- as you say, implementing the iana-if-type module means that all interface
types listed therein become valid.

So yes, I do believe that it would be useful if authoritative expert groups
develop a better structure of interface type identities.

Lada
  
On Thu, 2018-04-05 at 23:59 +0000, Alex Campbell wrote:
> Note this is not really to do with YANG itself, so much as the practical
> limitations of the software package that provides our CLI interface.
> We were wondering if it would make sense to introduce features in the IANA if
> types YANG model to enable grouping of related interface types.  This would
> allow implementations to include only the types it really requires (by
> supporting the related features but not the others) and (in case of a CLI
> interface) would reduce the possible completions if an operator would ask for
> the possible values of the type of an interface.
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Apr 2018 10:00:48 +0200 (CEST)

> develop a better structure of interface type identities.

I agree.  At the time when we did ietf-interfaces, not many people had
experience with using identities; and we didn't have YANG 1.1.  So we
just used what we had in the MIB, but as identities.  Now that we have
much more experience, it would be great to build a better way to
identify interfaces and their properties.

/martin

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 6 Apr 2018 08:12:03 +0000

Alex,

Not sure if this only has to do with "practical limitations providing a CLI interface"...   In a machine-to-machine interface this is less of a problem but in a human-to-machine interface it seems a bit impractical to me to find a solution for a problem to scroll through a list of 100+ completions if an operator would ask for the possible completion in case he does not know what to provide as input.  There are ways to limit this output but it can be solved on a modelling level as well.  As I indicated identities can be conditional to a feature and if implementations choose not to implement a set of interface-type related features the list becomes (a whole lot) shorter "by itself".  Now iana-if-type is just a collection of all interface types that have been defined once without any kind of "structure".

Regards, Bart

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Friday, April 6, 2018 9:55 AM
To: Alex Campbell <[email-masked]>; Bogaert, Bart (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]
Subject: Re: [netmod] An abundant amount of IANA if types...

Hi,

I have argued several times in the past that the IANA interface list (and, for that matter, the iana-if-type module) is a useless pile of rubbish because

- using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet is outright stupid

- as you say, implementing the iana-if-type module means that all interface types listed therein become valid.

So yes, I do believe that it would be useful if authoritative expert groups develop a better structure of interface type identities.

Lada
  
On Thu, 2018-04-05 at 23:59 +0000, Alex Campbell wrote:
> Note this is not really to do with YANG itself, so much as the 
> practical limitations of the software package that provides our CLI interface.
> From: netmod <[email-masked]> on behalf of Bogaert, Bart 
> (Nokia -
> BE/Antwerp) <[email-masked]>
> We were wondering if it would make sense to introduce features in the 
> IANA if types YANG model to enable grouping of related interface 
> types.  This would allow implementations to include only the types it 
> really requires (by supporting the related features but not the 
> others) and (in case of a CLI
> interface) would reduce the possible completions if an operator would 
> ask for the possible values of the type of an interface.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Apr 2018 10:18:30 +0200

If we would have a mechanism to deviate an identityref to a subset of
identity values supported by an implementation, we would have solved a
more generic problem. Yes, the IANA list could be 'nicer' but it will
never be 'nice'.

/js

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Apr 2018 10:51:48 +0200

> more generic problem. Yes, the IANA list could be 'nicer' but it will

Three mechanisms can be used for this:

- splitting the identities into separate modules
- using features
- using deviations (even though vendors frown on them)

I also proposed in the past to define the relevant identities in small
batches in the same module that defines other data (configuration, state
etc.) for the given interface type(s), rather than maintaining the
interface types as a separate registry.

I do admit that it is also useful to have such a registry but it can be
automatically compiled from the existing modules (for example, YANG
Catalog could do this).

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Apr 2018 13:36:39 +0200

> - splitting the identities into separate modules

Whatever module organization you come up with, it won't work for all
implementations. 

> - using features

Making every identity a feature will turn the feature system upside
down. This is similar to making every leaf a feature.

> - using deviations (even though vendors frown on them)

If my implementation only supports A and B and C, then a deviation may
state exactly that and the problem is solved. Hoping that my specific
combination of A and B and C matches a set of modules or some set of
features is in my view an illusion.

Vendors not shipping proper deviations are essentially telling their
customers that they have not yet understood model driven management.
We need to change the mindset here instead of polluting our data
models with hundreds or thousands of fine grained 'features'.

/js

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 6 Apr 2018 11:59:53 +0000

Juergen,

I was not suggesting to have a feature for all identities but I would assume that there are several identities that logically belong to each other so these could be grouped.  If this would still lead to a lot of features I do not see how a deviation can help out here to reduce the number of identities as you do not have a schema node for identities so to me the only way to reduce the amount of interface types one supports is to define a YANG module importing ietf-interfaces for the base interface-type identity and defining the set of identities required but then this not really in-line with what is coming from the standardization bodies (you could re-use the same names as used in iana-if-type but this is not very nice).

Regards, Bart

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, April 6, 2018 1:37 PM
To: Bogaert, Bart (Nokia - BE/Antwerp) <[email-masked]>; Alex Campbell <[email-masked]>; [email-masked]
Subject: Re: [netmod] An abundant amount of IANA if types...

On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> > If we would have a mechanism to deviate an identityref to a subset 
> > of identity values supported by an implementation, we would have 
> > solved a more generic problem. Yes, the IANA list could be 'nicer' 
> > but it will never be 'nice'.
> 

Whatever module organization you come up with, it won't work for all implementations. 

> - using features

Making every identity a feature will turn the feature system upside down. This is similar to making every leaf a feature.

> - using deviations (even though vendors frown on them)

If my implementation only supports A and B and C, then a deviation may state exactly that and the problem is solved. Hoping that my specific combination of A and B and C matches a set of modules or some set of features is in my view an illusion.

Vendors not shipping proper deviations are essentially telling their customers that they have not yet understood model driven management.
We need to change the mindset here instead of polluting our data models with hundreds or thousands of fine grained 'features'.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Apr 2018 14:01:30 +0200

> state exactly that and the problem is solved. Hoping that my specific

In fact, deviations cannot delete identity values because they aren't schema
nodes, so they are of no use.

> features is in my view an illusion.

An implementation that supports, say, a given type of tunnel interface will
implement the module that covers this tunnel type. If the identity for this
tunnel interface type is defined in the same module, then all is good. I don't
get why this should be an illusion. On the contrary, I think it is the cleanest
available solution to this conformance specification problem.

> models with hundreds or thousands of fine grained 'features'.

I agree that zillions of features aren't nice but it seems to be the only
solution that we currently have for modules of the iana-if-type style.

Having an bulky set of identity values, most of which are of no interest, is IMO
much worse and could also be a security issue if implementors aren't careful
enough.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Apr 2018 14:29:01 +0200

> nodes, so they are of no use.

Putting today's limits of YANG syntax aside for the moment, I still
believe implementations need to publish the identities they support
without requiring matching features or module definition.

> much worse and could also be a security issue if implementors aren't careful

If an implementation does not check input, then the code is broken,
regardless whether we restrict the identities somewhere or not. I do
not buy the security point.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Apr 2018 14:30:58 +0200 (CEST)

> models with hundreds or thousands of fine grained 'features'.

One problem is that you can't "deviate-away" support for an identity.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Apr 2018 15:22:47 +0200

> without requiring matching features or module definition.

OK, but then I certainly wouldn't call it a deviation.

> If an implementation does not check input, then the code is broken,

Come on, the cyberspace is full of such code. We should do our best to enable
schemas that are as strict as possible.

In XML, it should have been clear to everybody that hardwired namespace prefixes
are broken, and yet they were used so often that eventually the prefix-URL
duality was identified as a flaw of XML itself.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Fri, 6 Apr 2018 14:55:45 +0100

At the moment, I would say that the vast majority of the definitions in 
IANA.yang are just noise because they refer to definitions that are 
obsolete.  Our OS seems to use only 10% of the 287+ defined IANA types, 
and that 10% includes technologies such as frame relay, serial, atm, 
that very much seem to be on their way out.

Using hierarchical identities and interface properties seems like a 
reasonable solution to me (e.g. as described in 
draft-wilton-netmod-interface-properties-00).  E.g. so rather than 
having configuration with a direct when statement on a specific list of 
interface types, instead the when statement can depend on the 
appropriate interface properties.

I also like Lada's suggestion of trying to spread out the IANA 
definitions to the modules that are defining the technology.  So, if a 
device implements support for PPP configuration/operational state then 
it would also naturally define any PPP related interface identities at 
the same time.

If a vendor wants to define their own flavour of Ethernet interface then 
they can do so in their vendor specific module without requiring all 
tooling to become aware of it, and allowing the existing Ethernet 
configuration to work as normal.

>> Whatever module organization you come up with, it won't work for all
Yes, getting the root of this structure right is perhaps somewhat 
tricky, but I don't think that it needs to be all encompassing, or perfect.

> much worse and could also be a security issue if implementors aren't careful
I'm not sure there is a security concern here, but a long list where 
most of the values are cruft doesn't really seem to help anyone.  It 
also makes it harder to know which is the right type to use.  E.g. will 
everyone know that they should use "ethernetCsmacd" rather than 
"gigabitEthernet" for an optical GE interface that doesn't actually use 
CSMA/CD ...

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Apr 2018 09:03:35 -0700

Hi,

All of these suggested solutions seem OK if one were looking for the most
disruptive
way to solve the problem.  Tossing iana-if-types and starting over would
achieve that result.

First, this is a server capabilities problem, so it is related to the
implementation, not the schema.

Second, the if-types that are allowed at any given moment can be specific
to the implementation
and the interface name.

I think this is the 3rd time I have suggested an RPC to solve the actual
probem:

  rpc get-allowed-if-types {
    description
      "Retrieve the interface types allowed by the server.";
    input {
      leaf name {
         type if:interface-ref;
         description
            "If present, the server will return allowed interface types for
this interface name only.
             If not present, then the server will return all supported
interface types.";
       }
     }
     output {
         leaf-list type {
            type identityref {
               base interface-type;
            }
            description
              "Specifies a supported interface type";
        }
    }
 }

Andy

On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton <[email-masked]> wrote:

> obsolete.  Our OS seems to use only 10% of the 287+ defined IANA types, and
> that 10% includes technologies such as frame relay, serial, atm, that very
> much seem to be on their way out.
>
> draft-wilton-netmod-interface-properties-00).  E.g. so rather than having
> configuration with a direct when statement on a specific list of interface
> types, instead the when statement can depend on the appropriate interface
> properties.
>
> I also like Lada's suggestion of trying to spread out the IANA definitions
> to the modules that are defining the technology.  So, if a device
> implements support for PPP configuration/operational state then it would
> also naturally define any PPP related interface identities at the same time.
>
>> Yes, getting the root of this structure right is perhaps somewhat tricky,
> but I don't think that it needs to be all encompassing, or perfect.
>
> - using features
>>>>
> I'm not sure there is a security concern here, but a long list where most
> of the values are cruft doesn't really seem to help anyone.  It also makes
> it harder to know which is the right type to use.  E.g. will everyone know
> that they should use "ethernetCsmacd" rather than "gigabitEthernet" for an
> optical GE interface that doesn't actually use CSMA/CD ...
>
> Thanks,
> Rob
>
>
>
>> Lada
>>
>> /js
>>>
>>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 6 Apr 2018 09:24:13 -0700

Chassis based systems have line cards that support particular interface types. What happens to the output when a line card is plugged in or out of the system? In other words, is this a static or a dynamic list?

> On Apr 6, 2018, at 9:03 AM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> All of these suggested solutions seem OK if one were looking for the most disruptive
> way to solve the problem.  Tossing iana-if-types and starting over would achieve that result.
> 
> First, this is a server capabilities problem, so it is related to the implementation, not the schema.
> 
> Second, the if-types that are allowed at any given moment can be specific to the implementation
> and the interface name.
> 
> I think this is the 3rd time I have suggested an RPC to solve the actual probem:
> 
>             "If present, the server will return allowed interface types for this interface name only.
>              If not present, then the server will return all supported interface types.";
>        }
>      }
>      output {
>          leaf-list type {
>             type identityref {
>                base interface-type;
>             }
>             description
> On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
> At the moment, I would say that the vast majority of the definitions in IANA.yang are just noise because they refer to definitions that are obsolete.  Our OS seems to use only 10% of the 287+ defined IANA types, and that 10% includes technologies such as frame relay, serial, atm, that very much seem to be on their way out.
> 
> Using hierarchical identities and interface properties seems like a reasonable solution to me (e.g. as described in draft-wilton-netmod-interface-properties-00).  E.g. so rather than having configuration with a direct when statement on a specific list of interface types, instead the when statement can depend on the appropriate interface properties.
> 
> I also like Lada's suggestion of trying to spread out the IANA definitions to the modules that are defining the technology.  So, if a device implements support for PPP configuration/operational state then it would also naturally define any PPP related interface identities at the same time.
> 
> If a vendor wants to define their own flavour of Ethernet interface then they can do so in their vendor specific module without requiring all tooling to become aware of it, and allowing the existing Ethernet configuration to work as normal.
> 
> 
> 
> Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> writes:
> 
> Yes, getting the root of this structure right is perhaps somewhat tricky, but I don't think that it needs to be all encompassing, or perfect.
> 
> - using features
> I'm not sure there is a security concern here, but a long list where most of the values are cruft doesn't really seem to help anyone.  It also makes it harder to know which is the right type to use.  E.g. will everyone know that they should use "ethernetCsmacd" rather than "gigabitEthernet" for an optical GE interface that doesn't actually use CSMA/CD ...
> 
> Thanks,
> Rob
> 
> 
> 
> Lada
> 
> /js
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Apr 2018 09:39:48 -0700

On Fri, Apr 6, 2018 at 9:24 AM, Mahesh Jethanandani <[email-masked]
> wrote:

> Chassis based systems have line cards that support particular interface
> types. What happens to the output when a line card is plugged in or out of
> the system? In other words, is this a static or a dynamic list?
>
>
An RPC is inherently dynamic.
The output is based on the current state when the RPC is invoked.
There are lots of ways (e.g., proprietary trunk modes) that the interface
types
allowed can change dynamically.

BTW, the interface-ref in the input needs to be 'require-instance false'
to allow for interfaces that are not yet configured.

Andy

On Apr 6, 2018, at 9:03 AM, Andy Bierman <[email-masked]> wrote:
>> interface types, instead the when statement can depend on the appropriate
>> interface properties.
>>
>> device implements support for PPP configuration/operational state then it
>> would also naturally define any PPP related interface identities at the
>> same time.
>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 09 Apr 2018 12:45:10 +0200

> way to solve the problem.  Tossing iana-if-types and starting over would

I think nobody is suggesting to dump iana-if-types, just create an
alternative hierarchy of identities. So it's not disruptive at all. 

> implementation, not the schema.

I disagree, it is also a data modelling problem. What's needed is to be
able to define parameters that are common to e.g. Ethernet interfaces in
one place and let them be inherited by all Ethernet-like interfaces. The
flat list of identities - even if the contents was much better than it
currently is - allows to do it only in a way that's clumsy and
non-scalable.

>   rpc get-allowed-if-types {

But this is an ad hoc solution that works only for this particular
registry.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Apr 2018 10:48:04 -0700

> alternative hierarchy of identities. So it's not disruptive at all.

I guess we really disagree on the nature of the problem that needs to be
solved.
Since the "type" leaf and existing identities cannot be changed,
then it seems you are suggesting an entire new set of identities.
So servers will need to handle the old identities and the new ones.
Not disruptive, but not helpful either.

At the end of all of this work, the client will
still be unable to answer the question "What identities are allowed
for interface X on server Y, right now?"

I don't see how rearranging the identities lets the client know
what identities a server will accept to create or modify a particular
interface.

Andy

> and
> having
> definitions
> tricky,
> >>> tunnel interface type is defined in the same module, then all is good.
> I
> >>> don't
> >>> Having an bulky set of identity values, most of which are of no
> interest,
> >>> is IMO
> most