Re: [netmod] Question on intefaces-state model

On 13/06/2017 10:15, Vladimir Vassilev wrote:
> On 06/12/2017 08:31 PM, Andy Bierman wrote:
>
>>
>>
>> On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder 
>> <j.schoenwaelder@jacobs-university.de 
>> <mailto:j.schoenwaelder@jacobs-university.de>> wrote:
>>
>>     On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia -
>>     BE/Antwerp) wrote:
>>     >
>>     > We have a question regarding the statistics container as defined
>>     in the
>>     > interfaces-state model.  This container defines one mandatory leaf
>>     > (discontinuity-time) while all other leafs are optional.  What
>>     is the
>>     > rationale behind this leaf being mandatory and not an optional
>>     field?
>>     >
>>     > It does not make a lot of sense to return a discontinuity-time
>>     value and no
>>     > counters if none of the counters are relevant for a specific
>>     interface.
>>     >
>>     > Another alternative could be to add, via a deviation, a when
>>     clause to the
>>     > container indicating for which ifType(s) the container is (or is
>>     not)
>>     > present. But that would lead to not supporting the IETF
>>     interfaces model to
>>     > the full extent.
>>     >
>>
> The alternative which we use is to not have 
> /interfaces-state/interface/statistics container for the interfaces 
> without counters. The container is mandatory=false.
>>
>>
>>     The discontinuity-time is relevant for _any_ counter associated with
>>     an interface, regardless whether the counter is defined in the
>>     interfaces model or elsewhere. I have a hard time to imagine an
>>     interface that has zero counters.
+1

>>
> There are some though. Optical amplifiers and similar equipment that 
> does not have counters - the status data is only signal levels.
For me the question is here is whether the objects being modelled by 
optical amplifiers are actually interfaces or something else, and I 
think that they are probably something else.

I appreciate that this may not be the universal view, but I think of an 
interface as something that forwards traffic at layer 2 or above.  I.e. 
it is something that is potentially meaningful to have a IP address on, 
assign a routing protocol to, have frame or packet statistics, etc.

I would rather IETF defines a separate list of objects (e.g. Cisco's IOS 
XR would call them 'controllers') for L1 forwarding objects, given that 
most of the configuration and properties of these L1 forwarding 
constructs is generally quite different from 'regular' interfaces.

>>
>> The mandatory-stmt is very confusing for config=false nodes. 
>> Mandatory=true means
>> an <rpc-reply> must contain an instance of the mandatory leaf.
>>
>> 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?

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.

As an aside, I think that this is also why default values for config 
false leaves aren't helpful because they can cause ambiguity as to 
whether a server has no value to return, or is instead returning the 
default value.

Rob

>
>
> Vladimir
>>
>>
>>
>> /js
>>
>>
>> Andy
>>
>>     --
>>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | 
>> Germany
>>     Fax:   +49 421 200 3103 <http://www.jacobs-university.de/
>>     <http://www.jacobs-university.de/>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     netmod@ietf.org <mailto:netmod@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/netmod
>>     <https://www.ietf.org/mailman/listinfo/netmod>
>>
>>
>>
>>
>> _______________________________________________
>> 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
> .
>