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

Mahesh Jethanandani <> Tue, 18 May 2021 18:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 132DF3A1B29; Tue, 18 May 2021 11:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fzqnz0BA1pHF; Tue, 18 May 2021 11:01:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F49D3A1B16; Tue, 18 May 2021 11:01:01 -0700 (PDT)
Received: by with SMTP id g18so6333229pfr.2; Tue, 18 May 2021 11:01:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=31GeimpxqKdfPDRaKMxxisX2jSjfIFm/Jf1fn4sQUO0=; b=tTWdaJR162BHGkpaAHupHLJ2mxjOAVCeLxzyJkfSrCa6ZLJdyCD0Z9GD2jvW82I3ES 6e1/zQZLhXShxNA8WYIykH5AkkH1UGibo4mThScYt1beJoJyBYp7Wb/jQ1hMvzmTX71l K2fEWUI2MIKbReoY/yrU81T8sp8hmsWLiYg5QrxJiDDxOXLbB3qqhrtDDHLSb6ZtZ9yX fc+AUj/F6t47uFCqN8bpjNCxXzead5kGPLrMD1lYesFmSY0Dtk8F6F9wvydbjUe3Xldg yqYuBov1QvMxfHLtPnTQOq5xHOThAo5THzr9+L2FEKeR4/cP03c8Dcs0Hb0lVA5rQvo2 IFvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=31GeimpxqKdfPDRaKMxxisX2jSjfIFm/Jf1fn4sQUO0=; b=XhyrABTOfedEbnGkPfUuPlxu/JurOj1P4tlcoJhQm3TN9uOFxYeFKC2KVVbINTU3/5 3O6eUE+FksjvkHeVUGV6Tx4wTSYBdHMIg6tMhXjC/gQNL2iAFBXyRxuu7pZ5D1oGuUTw DCjG5Mz5CNne2v/P+r9+rYdmU01zqvCj0UbVBXnY3ZX1ekWwXY2VfMPf+GUBO7iDmZhv C4YCf67FSz9FRE90Xv1ITIPoYGCE3Lx/0/+U+hFHwsuK2IAPF3xiuUOQPPIwKkAx88kB wC3NpuPQ1RqYN3z4vCtO2jFsmHXvpodklBF8FDFx8jinEAzZJVQZuaTIXB04LBmGoVuu 1cwQ==
X-Gm-Message-State: AOAM532/oQQzCNpz3j3X2ExkQsDCssKPnHvzGgI2+tj9lCG1tiBhv2wm 4+vTjTPEHepkChqfE0m0ge8=
X-Google-Smtp-Source: ABdhPJybTJHrI64nnkJA3sQvZHJXgUeyqlbmj6LEn7HhpdxUjzKLeqZVnZSFMaw+5BloD2+1f3kbGg==
X-Received: by 2002:a05:6a00:162b:b029:27f:f30e:f0db with SMTP id e11-20020a056a00162bb029027ff30ef0dbmr6238285pfc.73.1621360859886; Tue, 18 May 2021 11:00:59 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:c54e:5d38:16e0:5235? ([2601:647:5600:5020:c54e:5d38:16e0:5235]) by with ESMTPSA id f6sm12342634pfe.74.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 May 2021 11:00:59 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_65AD0BD4-3257-4E18-AA7E-5FFCF158DBFE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 18 May 2021 11:00:55 -0700
In-Reply-To: <>
Cc: The IESG <>,, babel-chairs <>, Babel at IETF <>, Donald Eastlake <>
To: Martin Duke <>
References: <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [babel] Martin Duke's No Objection on draft-ietf-babel-yang-model-10: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 May 2021 18:01:07 -0000

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 <> 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
> for more information about DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> (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.


Mahesh Jethanandani