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

[Martin Duke <[e-mail]>]

Hi Barbara,

On Tue, May 18, 2021 at 11:48 AM STARK, BARBARA H <[e-mail]> wrote:

> The received-metric and calculated-metric are read-only parameters. They
> come from the babel implementation and are never provided from the data
> model to the implementation. Their calculation and use (by the
> implementation) is governed fully by RFC 8966. For the Babel routing
> protocol implementers, NULL (a variable of zero-length) and zero (a value
> of zero) are separate and distinct values. Various computer languages allow
> for this distinction – even when passing around integers. Data models (and
> relational databases like sql and such) often struggle with this
> distinction because they don’t allow zero-length integer fields.
>

Thanks for clarifying -- that's a fine distinction to make, although the
authors should agree that they're making it!


>
>
> If the route is originated by this router, advertised by this router, and
> never advertised by another router in the network, then the received-metric
> (per the implementation) will be NULL. If the router is going to advertise
> a route that it originates, it will have to generate a calculated-metric.
> It may calculate the calculated-metric for itself to be zero – thus
> ensuring, if it subsequently receives an advertisement from another router
> for the same route, the received-metric supplied by the other router will
> never be less than the calculated-metric it has.
>
>
>
> Anyway, this is why “This metric will be NULL if the route was not
> received from a neighbor but was generated through other means." Note that
> this sentence is about the **route** being received from a neighbor (or
> the **route** being generated through other means). The received-metric
> is never “generated”. It is populated by the neighbor-supplied metric for
> an advertised route. And when an entry in the route table is locally
> originated and there is no received value, then it needs to be properly
> noted that there is no value. An absence of received value is NULL, and not
> a value of zero.
>

This makes sense, but it's not what the text says! See my original email.


>
>
> What happens when both values are non-zero, is a matter of local
> implementation policy, as described in RFC 8966 3.5.2 and some of RFC
> 8966’s Appendices that provide examples for how metrics and costs can be
> computed and used. The data model has absolutely no say over what values
> are passed to it. But it is an error if it has no metric at all (received
> or calculated) for a route that is in the route table.
>
> Barbara
>
>
>
> *From:* Martin Duke <[e-mail]>
> *Sent:* Tuesday, May 18, 2021 1:10 PM
> *To:* Mahesh Jethanandani <[e-mail]>
> *Cc:* The IESG <[e-mail]>rg>; [e-mail];
> babel-chairs <[e-mail]>rg>; Babel at IETF <[e-mail]>rg>;
> Donald Eastlake <[e-mail]>
> *Subject:* Re: Martin Duke's No Objection on
> draft-ietf-babel-yang-model-10: (with COMMENT)
>
>
>
> 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
> <https://urldefense.com/v3/__https:/www.ietf.org/iesg/statement/discuss-criteria.html__;!!BhdT!1VEP6dtIBxS8iSbw9v3eXWj6dKDVxmAJwtD6CK8WYDmdULfjXSa496wEIOefq9NP$>
> 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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-babel-yang-model/__;!!BhdT!1VEP6dtIBxS8iSbw9v3eXWj6dKDVxmAJwtD6CK8WYDmdULfjXSa496wEIOvbIEVE$>
>
>
>
> ----------------------------------------------------------------------
> 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]
>
>
>
>
>
>
>
>
>
>