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

Martin Duke <martin.h.duke@gmail.com> Thu, 20 May 2021 19:24 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 6BCF43A2301; Thu, 20 May 2021 12:24:55 -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, 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 1m1z5nzelFgg; Thu, 20 May 2021 12:24:51 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 8FC503A22FE; Thu, 20 May 2021 12:24:50 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id a11so17798469ioo.0; Thu, 20 May 2021 12:24:50 -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=GRAQqdJotdwKnkvSg42Uopq45vuszltt3FUslH+FBEc=; b=N5knLKG03/ZPcz1yjMAMDTqnZSdiYdkTgn9rzzJvsBlh9XzSILmIdfgiZboaaauOMm Sp11n4jpYHH8vOzcGpqj8OhOB4Y6ghu1j5H9RpqigSwjDFCKU3gAT56Y6iYRqzgGutVw fHfT2i2kSgBSH6sWGPGZvmGrl4VcSIVDApSQo0/xKN9SXMe+IvnIFsOeV/weNIocpAKf ti56pJSLSQ6K3k9swheD43Tja+JoOqmITVbnbuTBw7Lz6EojJQhCsvM9Ogxyd07mZehV NHuYcLNDQx5Eb2lPrc/sRQ6d3vsOq+7IwiriRQpRRXPd+rg9PMZbgLdInhz/+18GWfBB JOug==
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=GRAQqdJotdwKnkvSg42Uopq45vuszltt3FUslH+FBEc=; b=d3849H6ShtozOQs6bx9LOUF+egW2ecZlKAwFJo5WChTqrtD7xBHAFxE9tZYF+t8KnD Fngp/4eALabtxiBsabgt6oFWHAl7flcnt0PlNLLORiWnGyJyIA4rNLVzW9FzZlhJoFjT /hEYidzfgOU+f1/gg+KhMXXQgYZWs0B+DMbfKY3moMaHJaNkimUonRSBS2TnOM02yYQ/ lWothKLiBr/n7KmfLTuGtK53t4dCi5gPa4Q0Ak81jkjW+kx4gVC1/FUisUoSjUHDUPRm evQj2OcRuDZJRN1LhZLnTVR0zxIduJcES/kRQDUZklOWjsBm6eQjY0/Y5CrKYM1utnyR KbJw==
X-Gm-Message-State: AOAM532lhhN9DJNku9rkofw7n0sQNAGUwROdmlkONYwl4CTL56+Y0ywF w/eDuWPG6YwptacMyBlDs2ie9ffNxnaMB6CgdKo=
X-Google-Smtp-Source: ABdhPJz2J+0ek6M4tnGhvZTxMZmAINlY1KW0cPzqlm0zKVHmL49v10jwKD1QmGkHYkLpEIE5YEdfzoyEgeWvhWEMekY=
X-Received: by 2002:a05:6602:446:: with SMTP id e6mr7501863iov.20.1621538688317; Thu, 20 May 2021 12:24:48 -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> <CAM4esxT76NZKJ_6--ryJSnpjtRs7Hkhg4KCrA_h322P1j+YXrQ@mail.gmail.com> <8310B1F3-BB5C-4882-99CE-21D6DA916D3A@gmail.com>
In-Reply-To: <8310B1F3-BB5C-4882-99CE-21D6DA916D3A@gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 20 May 2021 12:24:37 -0700
Message-ID: <CAM4esxR_cEBNmz2ODDg4deo_Hw8n5eijJMPeAEP+swXuMd=okQ@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: "STARK, BARBARA H" <bs7652@att.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="00000000000081c0d905c2c7e56c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/4n1xJXnfZbVHqvYmg62ngrzbiJs>
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: Thu, 20 May 2021 19:24:56 -0000

Yes, it does.

On Thu, May 20, 2021 at 12:15 PM Mahesh Jethanandani <
mjethanandani@gmail.com> 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 <martin.h.duke@gmail.com> wrote:
>
> 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
>>
>>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>
>
>