Re: [babel] Martin Duke's No Objection on draft-ietf-babel-yang-model-10: (with COMMENT)

[Martin Duke <[e-mail]>]

That's fine. In the original text, you refer to zero and NULL as if they're
separate quantities. As these are uints, I think s/NULL/zero would solve
the problem.

It would be helpful to clarify what happens when both values are nonzero.

On Tue, May 18, 2021 at 11:01 AM Mahesh Jethanandani <
[e-mail]> wrote:

> Hi Martin,
>
> You bring up a point that I have been struggling with.
>
> On May 17, 2021, at 2:10 PM, Martin Duke via Datatracker <[e-mail]>
> wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-babel-yang-model-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (2.3)
>
> leaf received-metric {
>           type uint16;
>           description
>             "The metric with which this route was advertised by the
>              neighbor, or maximum value (infinity) to indicate the
>              route was recently retracted and is temporarily
>              unreachable. 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
>              calculated-metric or received-metric MUST be non-NULL.";
>           reference
>             "RFC ZZZZ: Babel Information Model, Section 3.6,
>              RFC 8966: The Babel Routing Protocol, Section 2.1.";
>         }
>
>         leaf calculated-metric {
>           type uint16;
>           description
>             "A calculated metric for this route. How the metric is
>              calculated is implementation-specific. Maximum value
>              (infinity) indicates the route was recently retracted
>              and is temporarily unreachable. At least one of
>              calculated-metric or received-metric MUST be non-NULL.";
>           reference
>             "RFC ZZZZ: Babel Information Model, Section 3.6,
>              RFC 8966: The Babel Routing Protocol, Section 2.1.";
>         }
>
> I don't understand the relationship between these two. If the metric was
> calculated rather than received, why would the value be zero instead of
> NULL?
> Isn't a zero metric dangerous in a routing algorithm?
>
>
> How do you represent NULL? By definition, NULL means there is no value,
> that we are looking at an empty leaf. A ‘received-metric’ per my reading,
> cannot be empty. It is either received from a neighbor, or is a generated
> value, and therefore cannot be empty. Same is the case for
> ‘calculated-metric’. Combine this with the fact that the info model defines
> the leaf of type unsigned int 16, and thus the value of 0. Would it help to
> add something to this effect?
>
> "A value of 0 implies a NULL value, and SHOULD NOT be used in metric
> calculation".
>
> Alternatively, one could change the type to signed int 16, something the
> TR-181 model does. In that case the value has two meanings. If the value is
> less than 0, it means the value is NULL, but if the value is greater than
> 0, then it carries the actual metric value??
>
> In either case, an implementor cannot take the value of the metric as is
> and use it, without checking if it is 0 or -1.
>
>
> (4) "config true perspective"
>
>
> Dropped the phrase from the sentence.
>
> Thanks
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>
>
>