Re: [babel] info-model: calculated and received metrics

[Mahesh Jethanandani <[e-mail]>]

Any reason we cannot change babel-route-received-metric/babel-route-calculated-metric be a int instead of a uint, and all negative values used to signify that the value is NULL/not set?

> On Jul 17, 2019, at 6:58 AM, STARK, BARBARA H <[e-mail]> wrote:
> 
> I've heard no response to this question. I've confirmed that in TR-181 I do have a problem (a uint with value of 0 or NULL will be transmitted in a TR-181 data model as 0), because it defines "NULL" as:
> ------------- excerpt from TR-106 Data Model Template --------------------
> Each primitive data type has an associated null value that is used, for example, as the expansion of the {{null}} template (A.2.2.4). These null values are defined as follows:
> * base64, hexBinary, string: an empty string
> * unsignedInt, unsignedLong: 0
> * int, long: -1
> * boolean: false
> * dateTime: 0001-01-01T00:00:00Z (the Unknown Time; see Section 3.2.1)
> A null reference indicates that a reference parameter is not currently referencing anything. The value that indicates a null reference is the null value for the reference parameter's base data type, i.e.:
> * string: an empty string
> * unsignedInt: 0
> * int:
> -------------------------
> But since the problem is just in the reporting and not in the Babel implementation's use of the values, maybe I should just mention that users should be careful when interpreting 0, since it can mean the value was not received / calculated?
> 
> What I could do is something like:
> 
>   babel-route-received-metric:  The metric with which this route was
>      advertised by the neighbor, or maximum value to indicate the route
>      was recently retracted and is temporarily unreachable (see
>      Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]).  This metric will
>      be NULL if the route was not received from a neighbor.  At least one of babel-route-
>      calculated-metric and babel-route-received-metric MUST be non-
>      NULL.  Having both be non-NULL is expected for a route that is
>      received and subsequently advertised.  This is a 16-bit unsigned
>      integer. Some data models may be unable to distinguish between 0 (zero)
>      and NULL for unsigned integers, which will cause NULL values to be
>      reported as 0.
> 
>   babel-route-calculated-metric:  A calculated metric for this route.
>      How the metric is calculated is implementation-specific.  Maximum
>      value indicates the route was recently retracted and is
>      temporarily unreachable (see Section 3.5.5 of
>      [I-D.ietf-babel-rfc6126bis]).  At least one of babel-route-
>      calculated-metric and babel-route-received-metric MUST be non-
>      NULL.  Having both be non-NULL is expected for a route that is
>      received and subsequently advertised.  This is a 16-bit unsigned
>      integer. Some data models may be unable to distinguish between 0 (zero)
>      and NULL for unsigned integers, which will cause NULL values to be
>      reported as 0.
> 
> Barbara
> 
>>>> For a route to exist in the info model babel-routes object, either
>>>> the received or calculated metric MUST be non-zero (rfc6126bis only
>>>> mentions the received metric as being in its route table).
>>> 
>>> Zero is a perfectly fine value for a metric (actually, the very best).
>>> Perhaps you meant defined instead of non-zero?
>> 
>> I don't think I got the descriptions for calculated and received metrics right,
>> given Juliusz statement that 0 is the best possible metric. What I'm struggling
>> with, is what value is assigned to these parameters when they aren't
>> received (for the received metric) or calculated (for the calculated metric)?
>> Should they be "null"? Wouldn't that be a problem in systems/languages that
>> don't distinguish between 0 and null for integer types? Or are there no such
>> languages/systems?
>> 
>> Here are the descriptions in the current draft:
>> 
>>   babel-route-received-metric:  The metric with which this route was
>>      advertised by the neighbor, or maximum value to indicate the route
>>      was recently retracted and is temporarily unreachable (see
>>      Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]).  This metric will
>>      be 0 (zero) if the route was not received from a neighbor but was
>>      generated through other means.  At least one of babel-route-
>>      calculated-metric and babel-route-received-metric MUST be non-
>>      zero.  Having both be non-zero is expected for a route that is
>>      received and subsequently advertised.  This is a 16-bit unsigned
>>      integer.
>> 
>>   babel-route-calculated-metric:  A calculated metric for this route.
>>      How the metric is calculated is implementation-specific.  Maximum
>>      value indicates the route was recently retracted and is
>>      temporarily unreachable (see Section 3.5.5 of
>>      [I-D.ietf-babel-rfc6126bis]).  At least one of babel-route-
>>      calculated-metric and babel-route-received-metric MUST be non-
>>      zero.  Having both be non-zero is expected for a route that is
>>      received and subsequently advertised.  This is a 16-bit unsigned
>>      integer.
>> 
>> Barbara
>> 
>> _______________________________________________
>> babel mailing list
>> [e-mail]
>> https://urldefense.proofpoint.com/v2/url?u=https- <https://urldefense.proofpoint.com/v2/url?u=https->
>> 3A__www.ietf.org_mailman_listinfo_babel&d=DwICAg&c=LFYZ-
>> o9_HUMeMTSQicvjIg&r=LoGzhC-
>> 8sc8SY8Tq4vrfog&m=sRdmY_yz1rFLX_CUhRDGHkslpc0QQlaKGcJIsOCpK0s&s
>> =C8UEVNQ3LdSS0-QKrh8puspZGHWfGPY65gDV-zHQbzI&e=
> 
> _______________________________________________
> babel mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>
Mahesh Jethanandani
[e-mail]