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

Martin Duke <martin.h.duke@gmail.com> Tue, 18 May 2021 21:39 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60483A100C; Tue, 18 May 2021 14:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAFHGK70OfBG; Tue, 18 May 2021 14:39:52 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2043A1009; Tue, 18 May 2021 14:39:52 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id z24so10946558ioj.7; Tue, 18 May 2021 14:39:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7UyYdY4AnOVbBLnwGIuA/Ah+PFIYF2CG6X1rrblPXgc=; b=nSdczCgW/q3XKbkH1n0/KQeFCmr/vWTZoR1WnvV9Uzhb+FP9xDhD9mAoE/QLBDm61q E0RQj37yzPX9eyR2RflBWL4MoUqY4EifRGnhGdKYsq7pPHDmbXfI1zOS9R8qbzeQmvQR 6r88ofYZTygAwLIecrgxZYZJuful6j2OSyZU84K/thNcn4ZSmhoyXX1pz2ABTZJ5j+G0 zX2l98NC74sZZyIgvK9M3yCBfNHnp+GS9UFEFjuTtNq+2usqXFBthBrL87twZ1g3IAnQ qUn+OyQiPmr7i6a+y+gR1ApPOtglGDigPBlxGf4knOXda4hcQWQKgYqnOL9eRHFARkqZ b5HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7UyYdY4AnOVbBLnwGIuA/Ah+PFIYF2CG6X1rrblPXgc=; b=RI/ngB7KbmQkM847hAZL1HLSm3Gb8Bx4/JVZtxz2CYnkpk39a5547SOCL7hwb2DUpM YBQrhlCojZoEYuM1b6WzhsnISNinzPJRjiBTL3M8ZQg6Cn9mIndFyGZ1gVbFNblija6v p7+aO0lTAoMYQqDqmc0jBiTYEQenUkD9GvdnqLxqmcgjshZgxzLi1wNhTTG0qhcrip6W JbhoKQVFIZi4NTVem2oLt+DxVuv24jUuz+MLzA/9pEesuf+4NWJgq9IzxFCxI2+cB076 k++No5LpJcqBk1N7Z4ZrRPIFhirfqArJpoAQr92wzvcJMPl4qDzbPCjqzaDYH8dhF06a D/fA==
X-Gm-Message-State: AOAM531T4UPzcnSgAC2XhWSiPd2DEwSJ9gCbFs4FZPxBWv+heqL0qEmc LX7/pu7RmH7/xulVMr35Kh3g8vzoB0cHexA54M4=
X-Google-Smtp-Source: ABdhPJxVY4lWxg+FKJyVscvjlXtFJP9PDG1VY6Mj7yd4SpgObWpGteF90kMXEsaZJ0wkC0WbMzMZarEWLml+CvNM5OI=
X-Received: by 2002:a5e:c10e:: with SMTP id v14mr6222850iol.51.1621373989911; Tue, 18 May 2021 14:39:49 -0700 (PDT)
MIME-Version: 1.0
References: <162128583297.9778.8228421381328520899@ietfa.amsl.com> <260E6E49-BB6D-4195-BD12-673A946FF346@gmail.com> <CAM4esxQLR-ULMf-RRT5_7y0U55zy+EqCqi7FhFhDtGitRz7LxA@mail.gmail.com> <DM6PR02MB692424BDA3D24B163D1E37F4C32C9@DM6PR02MB6924.namprd02.prod.outlook.com>
In-Reply-To: <DM6PR02MB692424BDA3D24B163D1E37F4C32C9@DM6PR02MB6924.namprd02.prod.outlook.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 18 May 2021 14:39:46 -0700
Message-ID: <CAM4esxT76NZKJ_6--ryJSnpjtRs7Hkhg4KCrA_h322P1j+YXrQ@mail.gmail.com>
To: "STARK, BARBARA H" <bs7652@att.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-babel-yang-model@ietf.org" <draft-ietf-babel-yang-model@ietf.org>, babel-chairs <babel-chairs@ietf.org>, Babel at IETF <babel@ietf.org>, Donald Eastlake <d3e3e3@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b77ee405c2a18c51"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/XLKpvIC8QNLKpZdtw1uyL7UUFmE>
Subject: Re: [babel] Martin Duke's No Objection on draft-ietf-babel-yang-model-10: (with COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2021 21:39:57 -0000

Hi Barbara,

On Tue, May 18, 2021 at 11:48 AM STARK, BARBARA H <bs7652@att.com> 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 <martin.h.duke@gmail.com>
> *Sent:* Tuesday, May 18, 2021 1:10 PM
> *To:* Mahesh Jethanandani <mjethanandani@gmail.com>
> *Cc:* The IESG <iesg@ietf.org>rg>; draft-ietf-babel-yang-model@ietf.org;
> babel-chairs <babel-chairs@ietf.org>rg>; Babel at IETF <babel@ietf.org>rg>;
> Donald Eastlake <d3e3e3@gmail.com>
> *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 <
> mjethanandani@gmail.com> 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 <noreply@ietf.org>
> 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
>
> mjethanandani@gmail.com
>
>
>
>
>
>
>
>
>
>