Re: [netmod] Question on intefaces-state model

Vladimir Vassilev <vladimir@transpacket.com> Wed, 14 June 2017 14:36 UTC

Return-Path: <vladimir@transpacket.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 E5981127868 for <netmod@ietfa.amsl.com>; Wed, 14 Jun 2017 07:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 4z7TIWsnmN0k for <netmod@ietfa.amsl.com>; Wed, 14 Jun 2017 07:36:57 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82CC126E01 for <netmod@ietf.org>; Wed, 14 Jun 2017 07:36:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 341FB1540613; Wed, 14 Jun 2017 16:36:54 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wkbRD8Am4tZl; Wed, 14 Jun 2017 16:36:54 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id EAA9B154061B; Wed, 14 Jun 2017 16:36:53 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VpKwBn_1ikMn; Wed, 14 Jun 2017 16:36:53 +0200 (CEST)
Received: from [192.168.209.116] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 9C94F1540613; Wed, 14 Jun 2017 16:36:53 +0200 (CEST)
To: "Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Robert Wilton <rwilton@cisco.com>
References: <AM2PR07MB06272FF9E8BA4D00B0669F9794CE0@AM2PR07MB0627.eurprd07.prod.outlook.com> <20170612172141.GA52797@elstar.local> <CABCOCHSK1h4HQ4LgkYd_Lxp3JYzxYBMmCka64_-iVjq2N_PR7g@mail.gmail.com> <65e1aa8e-c37b-d323-a351-c17fa4e96b3e@transpacket.com> <c436c7ac-b5f5-7bbf-8bea-bf109f390b11@cisco.com> <20170614093943.GA56060@elstar.local> <AM3PR07MB06326396CA85ADDE72A4288094C30@AM3PR07MB0632.eurprd07.prod.outlook.com>
Cc: Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org>
From: Vladimir Vassilev <vladimir@transpacket.com>
Message-ID: <57ca71ae-b397-589a-dd74-1ae0df1bb7c5@transpacket.com>
Date: Wed, 14 Jun 2017 16:36:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: <AM3PR07MB06326396CA85ADDE72A4288094C30@AM3PR07MB0632.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Ek-GX1kTCMUqeI6ufwauHdVnXwg>
Subject: Re: [netmod] Question on intefaces-state model
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: Wed, 14 Jun 2017 14:37:00 -0000

Hello,

On 06/14/2017 01:18 PM, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
> That's why these counters are optional in the model: if there is nothing to
> return we should indeed not return 0...
>
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: 14 June 2017 11:40
> To: Robert Wilton <rwilton@cisco.com>
> Cc: Vladimir Vassilev <vladimir@transpacket.com>; Andy Bierman
> <andy@yumaworks.com>; Bogaert, Bart (Nokia - BE/Antwerp)
> <bart.bogaert@nokia.com>; netmod@ietf.org
> Subject: Re: [netmod] Question on intefaces-state model
>
> On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote:
>> Returning zero values here is not useful, in fact it is misleading. I
>> think that if a server doesn't have a value to return for a particular
>> node it is much better to return nothing than to return a false value.
> +1.
>
> It took us years to kill this attitude in SNMP land. Saying a counter is
> zero and never changes is largely misleading if you actually have no such
> counter. It is easy to waste hours of expensive engineering time by given
> people fake counters.
>
> /js
>

I agree that the statistics counter leafs as defined in ietf-interfaces 
are optional except the discontinuity-time ("mandatory true;") leaf. You 
were right it makes the entire /interfaces-state/interface/statistics 
container mandatory even if none of the optional counters are implemented.

The context of the example was the statement by Andy who seemed to 
differ on the counters being optional. I was not sure what he ment and 
added an example of device not implementing some of the counters without 
breaking conformity with ietf-interfaces:

On 06/13/2017 11:15 AM, Vladimir Vassilev wrote:
> On 06/12/2017 08:31 PM, Andy Bierman wrote: an <rpc-reply> must 
> contain an instance of the mandatory leaf.
>> The mandatory-stmt is very confusing for config=false nodes. 
>> Mandatory=true means
>> Mandatory=false does not mean optional-to-implement although it sure
>> looks that way for config=false nodes.  Only if-feature can make a 
>> node optional to implement.
> If we take serial interface with hardware that only has in-octets and 
> out-octets counters I would expect to only find these two in 
> /interfaces-state/interface/statistics +  discontinuity-time. Do you 
> say the rest of the counters must be present (e.g. allways 0) for 
> proper implementation of ietf-interfaces? 

That said you probably also agree that a model with optional leafs is 
equivalent to an employment contract where the monthly salary is 
optional. State data models should avoid the entropy of allowing 
implementations to either implement or not leafs without this being 
formal conformance deviation (this being especially valid for basic 
counters part of the base ietf model like ietf-interfaces). That causes 
greater waste of not only engineering time but runtime traffic as well. 
Management applications have to be designed to poll the leafs and make 
conditional decisions for each instance and handle missing leafs to 
conform to the model.

For example an option to do automated validation of all point to point 
links in a topology (by checking counters at source and destination 
ports - out-unicast-pkts=in-unicast-pkts ... etc.). All the devices 
implement the required capability - ietf-interfaces but some do not 
return out-unicast-pkts, out-broadcast-pkts, out-multicast-pkts since 
the hardware only provides them with out-total-pkts and in-total-pkts 
(not part of ietf-interfaces model).


With that example in mind I have another relevant question:

Is there consensus that this is valid YANG 1.1 and with a mandatory 
counters defined like that the stated conformance actually brings some 
guarantees the required counter will be implemented:

...

yang-version 1.1;

...

    augment "/if:interfaces-state/if:interface/if:statistics" {
         leaf in-total-pkts {
           mandatory true;
           type yang:counter64;
         }
         leaf out-total-pkts {
           mandatory true;
           type yang:counter64;
         }

     }

...

pyang does not like that ("cannot augment with mandatory node 
in-total-pkts") and I think it should be valid to add mandatory true 
counter leafs to /interfaces-state/interface/statistics

Vladimir