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

Andy Bierman <andy@yumaworks.com> Mon, 09 April 2018 17:48 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 0CFF412D777 for <netmod@ietfa.amsl.com>; Mon, 9 Apr 2018 10:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level:
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 LY8BkH8PaKjk for <netmod@ietfa.amsl.com>; Mon, 9 Apr 2018 10:48:07 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 4387B1200FC for <netmod@ietf.org>; Mon, 9 Apr 2018 10:48:07 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id c78-v6so7804498lfh.1 for <netmod@ietf.org>; Mon, 09 Apr 2018 10:48:07 -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; bh=+9wZ9NE6VK1W1iTDbjzIqe/MbYSkNI1Kmc/ya06/6gk=; b=yD80IBgZd2rrldvVqAUTq/AbTD7i/f6Y/oKdyF4UKkEPKI7GmImE2JzePUAxIzv9Ji 5AWprSW50PA1UQdQn9bK+fmBv4zz4RedGzjfG5xm3McnEBYlKqKlP36N6T7F0ScBMDrV L6MrK4nJRgi8zKD7yKPTiByGN0DWPjoudWh1PxSZrdGiZsnRSmdg0d36ywY+7yM8gRGk Zq3tzyxpCTDcfPgWAlRJAgDtl8ITQLb0H2SFmGpkSBRyzxQ7ftlADgCXD9RyVQNynxt3 Mv4CyCwc6i9VUj6cWjfqxUba8zWb6Ta8Q6I8zjUotlEZ527Q+7peEI73fYxJ0chce3tZ utvQ==
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; bh=+9wZ9NE6VK1W1iTDbjzIqe/MbYSkNI1Kmc/ya06/6gk=; b=JZ3jyYLBwUpTNokxZAkTGfula/x9++cCegmlz4W7+6qSUKjwkpOdAdT83RZQN5cyke JqFSJ7YRRGRWpVlSjJ1DDgjWPGEGtxkVnFv+LxzMk0rEuUNzKAZ8lbsOEMjEZ4UBuDF2 h2c34tRqhNikCdEc8wVo2Nyd2YmOYjTqduS4TdGn92xrJa2AY23rQ/oFxxUnDWz5Qf2j GVtlWtgm5Kj3w8o4L3g4yuyN1QL39TXT4xp30xSv+xJPC/jgPALWrkcIvgz6AzwdaE1Z zHLd7+/SCxnhKw46af3Yc/w2A+RtEbPGP1ds9pr2P6eXBtooFEFTQRsVb3X+X+RSi48J MJvQ==
X-Gm-Message-State: ALQs6tCAVyAPq5vphnDShsqu5P5wk6iq4hHzQBKhYcC6biZ5rO01gct7 VsvIMWONInVLlLH7Avq4HVKIleY+0KwBKfgVkSyykA==
X-Google-Smtp-Source: AIpwx4/s+esdosqC4Nhrh4MB1VN2qdyg4hEVTH/D3LO4D2bGyapLYj+9f6+fjOy8FwB1/XAit3SuYAR+G3D9pYqKQMA=
X-Received: by 2002:a19:101a:: with SMTP id f26-v6mr23383232lfi.42.1523296085386; Mon, 09 Apr 2018 10:48:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:5149:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 10:48:04 -0700 (PDT)
In-Reply-To: <87in90odzd.fsf@nic.cz>
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> <87in90odzd.fsf@nic.cz>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 9 Apr 2018 10:48:04 -0700
Message-ID: <CABCOCHSrh69aNHMzDnhAY5ZaUiNN7-DWJKAu+3bRBfQp8LqjSA@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>, Robert Wilton <rwilton@cisco.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000ec27c05696e02f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/AsR8NTzYVBrpaCiKAnOjVMC883k>
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: Mon, 09 Apr 2018 17:48:11 -0000

On Mon, Apr 9, 2018 at 3:45 AM, Ladislav Lhotka <lhotka@nic.cz>; wrote:

> Andy Bierman <andy@yumaworks.com>; 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.
>
>

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


>
> > 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 <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
> >>
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>