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

[Martin Duke <[e-mail]>]

Yes, it does.

On Thu, May 20, 2021 at 12:15 PM Mahesh Jethanandani <
[e-mail]> wrote:

> Hi Martin,
>
> Barbara and I did some wordsmithing offline and came up with the following
> description text for ‘received-metric’.
>
> OLD:
>
>              "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.";
>
>
> NEW:
>              "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 NULL (no value) if the
>               route was not received from a neighbor but instead was
>               injected through means external to the Babel routing
>               protocol. At least one of calculated-metric or
>               received-metric MUST be non-NULL.";
>
> Does this address your COMMENT?
>
> Thanks
>
> On May 18, 2021, at 2:39 PM, Martin Duke <[e-mail]> wrote:
>
> 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]>; [e-mail];
>> babel-chairs <[e-mail]>; Babel at IETF <[e-mail]>;
>> 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]
>>
>>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>
>
>