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

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

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

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

>
> First, this is a server capabilities problem, so it is related to the
> 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.

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

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

Lada

>     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 <[e-mail]> 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.
>>
>>
>>
>> On 06/04/2018 13:01, Ladislav Lhotka wrote:
>>
>>> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
>>>
>>>> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
>>>>
>>>>> Juergen Schoenwaelder <[e-mail]> writes:
>>>>>
>>>>> 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'.
>>>>>>
>>>>> Three mechanisms can be used for this:
>>>>>
>>>>> - splitting the identities into separate modules
>>>>>
>>>> Whatever module organization you come up with, it won't work for all
>>>> implementations.
>>>>
>>> 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
>>>>>
>>>> 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
>>>>
>>> In fact, deviations cannot delete identity values because they aren't
>>> schema
>>> nodes, so they are of no use.
>>>
>>> combination of A and B and C matches a set of modules or some set of
>>>> 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.
>>>
>>> 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'.
>>>>
>>> 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.
>>>
>> 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
>>>>
>>>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>

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