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

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 10 Jul 2019 18:32:33 +0000

> > 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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 17 Jul 2019 13:58:49 +0000

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
> 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?
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> 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=

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 17 Jul 2019 22:50:40 +0200

"STARK, BARBARA H" <[email-masked]> writes:

> 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:

In this case, wouldn't NULL be signified by the value being absent?

-Toke

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 17 Jul 2019 14:41:59 -0700

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 <[email-masked]> wrote:
> 
>> https://urldefense.proofpoint.com/v2/url?u=https- <https://urldefense.proofpoint.com/v2/url?u=https->
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>
Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 17 Jul 2019 21:54:14 +0000

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 <[email-masked]>

On Jul 17, 2019, at 6:58 AM, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:

------------- excerpt from TR-106 Data Model Template --------------------

Barbara

Barbara

[email-masked]<mailto:[email-masked]>

_______________________________________________
babel mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 17 Jul 2019 21:58:40 +0000

> In this case, wouldn't NULL be signified by the value being absent?

There's a difference between "the parameter doesn't exist within the data model" or "you don't have permission to read this parameter" (both are signified by absence of the parameter in TR-181) and "the parameter exists and you're allowed to read it but its value is NULL".
Barbara