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

["STARK, BARBARA H" <[e-mail]>]

I did think about that, and would be ok with it. I also considered stating in the description that data models that don't distinguish between NULL and 0 can use int (negative numbers can represent NULL). Otherwise use uint is fine.
Barbara

From: 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]<mailto:[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]<mailto:[e-mail]>
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_babel&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=hsquxyVEg_cNK32ZzUpKsmHk0F3Q3tx5gmjJQf2xLPo&s=aO_aczyKjyoXceg-qMimwrhIg3roTGEHfBjG407NN_Q&e=>

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>