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

Andy Bierman <andy@yumaworks.com> Fri, 06 April 2018 16:39 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D49112025C for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 09:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZehLhLDVIPn for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 09:39:51 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004F51200C5 for <netmod@ietf.org>; Fri, 6 Apr 2018 09:39:50 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id z143-v6so1400383lff.3 for <netmod@ietf.org>; Fri, 06 Apr 2018 09:39:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xar6v1YlV5qur1KT01UH8MW+SLcp0tHceLlChcuDhMc=; b=RGa63z8Ai4uLs2+ddd4Mt06hmWfVY8QpjOPgFI6VQIk+UkGwrrBujrYOisIHM60wWD W912Uz9VyKhcSYiJ29bXt6nUP7xNIJ6xp1kj0zOLf6X93zN+2VnzKIxjcGLpMZwWnAad P55nYPP7c91DIs+Mm11O7qg4B5sW3uoF9LJvfPwr5ARbvBt9aGHwm0HMRNZC2JwIqOK4 Uv0PYM4j9ZV3eY4TPph5JGIOGOdTwvfZ/Zp9aDacJukAdiDem8Q/gDfFVngH+YHqer8F NBn7Os3yEAj8G6l4Qu1/QK9BoQywH2h4K4kKIyMv3VWcoyfOsWONY0MRgzdJtiDevntj dxfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xar6v1YlV5qur1KT01UH8MW+SLcp0tHceLlChcuDhMc=; b=JaRSAena7jumaBfRh4tRr8yHEkli42ks+so9rhXKhk+zM9D7utl+FfWhI8d8LEAURa Ct+W3qgWVAiQBc6ErEH2xn0b1dA8gMH6y4EnYZpsYF11XYUS1eLrzRE+uTsKDgY2WlZt EtGzXW93Y0x7vma3XvIoIby++tMVGKuQ/ocO3AMxnay7xBiXeGVQiyQ0+ql5oeM/3bKl hblEleClN0P8dXyIiNw0YE4kbw1tS31Aq5ZxUtUlSBOZZMJRWQr/3F5ddEkwE1fchd2q h3zR0NyKnB+jGwa+P6/Ncp5EXjR1Ws9VZ/nm64uRCPGoC/AOLUIsjxvHIdGFPulTuOlV u1Aw==
X-Gm-Message-State: ALQs6tD+ji1S2C2tBo4ZI+PK9+7e/QwSMwZ2EhDPzeyeo1cR3oYpoVuk ROjnFNeZrRXpgSvJ+o3vv+uA937ZE/x6iRGkpylhVQ==
X-Google-Smtp-Source: AIpwx4/K/pEt2Xyc0byu1G9HhEJgg859gZazybTKN4rtQSQIR896aNB9yMX++ZZ8RM/5keFANXtCiF2FUJOP5ri2Jfc=
X-Received: by 10.46.29.140 with SMTP id w12mr16939810lje.108.1523032789229; Fri, 06 Apr 2018 09:39:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:5149:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 09:39:48 -0700 (PDT)
In-Reply-To: <C47EB610-F0F6-4B9C-8E01-B2328D3FF58F@gmail.com>
References: <AM4PR07MB1716AECAC144285D98B0E1EE94BB0@AM4PR07MB1716.eurprd07.prod.outlook.com> <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <AM4PR07MB1716DDB1796AA320616F7C0F94BA0@AM4PR07MB1716.eurprd07.prod.outlook.com> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> <4c3be475-0b9c-5837-5d08-115201b43305@cisco.com> <CABCOCHQ5SegNXOruRERvpG0EHu+irgYbewiUBzV3fDXNQMVaDA@mail.gmail.com> <C47EB610-F0F6-4B9C-8E01-B2328D3FF58F@gmail.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 6 Apr 2018 09:39:48 -0700
Message-ID: <CABCOCHSQPy8qQQv3x756iWa2mncv6kqGQ2yCW-WVOCw_pUqx0Q@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Robert Wilton <rwilton@cisco.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1a6636623932056930b452"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/5JxzWPg9UbWKC8Mza674t4hLWtQ>
Subject: Re: [netmod] An abundant amount of IANA if types...
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2018 16:39:54 -0000

On Fri, Apr 6, 2018 at 9:24 AM, Mahesh Jethanandani <mjethanandani@gmail.com
> 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 <andy@yumaworks.com> 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:
>
>   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 <rwilton@cisco.com> 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 <j.schoenwaelder@jacobs-university.de> 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
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>