Re: [babel] [netmod] NULL value for uint16

Mahesh Jethanandani <mjethanandani@gmail.com> Mon, 13 September 2021 19:49 UTC

Return-Path: <mjethanandani@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 C09933A0138; Mon, 13 Sep 2021 12:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 6KQvWoA0KTBF; Mon, 13 Sep 2021 12:49:37 -0700 (PDT)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 E69963A012A; Mon, 13 Sep 2021 12:49:36 -0700 (PDT)
Received: by mail-pf1-x429.google.com with SMTP id j6so9561428pfa.4; Mon, 13 Sep 2021 12:49:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XhOaN0avawxbgB1O4GKRepvvrGSnBj6nFW2MkQ1I9w8=; b=me2UCDLN4WJdLfqfq778WCq4fxFk5ux5ptgyMfOUoxAiGd3RKcmniS8tRdSn+QIuKv 2uWViZ4povCtWUjo0GTLif1x3OfQJemXHDHL3o/FUMJVWKyCkHOBeAP4mDjP+dV16SA3 DRddSlQESCsoUzEB7v6asbd6i3OznMKnC+UXIr0rw2PfG5nSvO9JdRjXoEC/PDJlygdY 0MjNgTkT+Qe2v2o8Y2fMy+9mrr+tCgpQ+IkowCXfbgoW71vEUGPSTjNClmvajzOCqkao 1qL5gV94I0bVWMMRU5mYQiPNJm8GrFTi3UrtHdE5ApmWvEYfjzCMZN5sr/3lUMeFUuEr AzvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XhOaN0avawxbgB1O4GKRepvvrGSnBj6nFW2MkQ1I9w8=; b=c9iU+WRRBwGyDT56QOeeTv6w9PnSDPUxpCV1rl+nJLnWAvwZVhno18PX7cUxqEFXpN ZjAHD9/Bn7neFWtUJFVEpcmtPAPT4QGU86i1wcV9TD5esL7XRQOLAXCnfpshIiDLzWrW taqE89KB9+E8u2bkGA3+zoQSFb1zeys7BtVmJsd2vLlfXnwVDeJKkl/DsRRa9iSyUq1t /ZSEzNaeYzdl/DHVZdJ08Bu++qZCQ+YeGRq2QYk6z4zItz7XIpfLTlS1Yn03+jBZAc/Q XIk09ej03KjSeuzkeJD4onatrlSx8B/Y9unxexAqNOEU0sMsIOdYo2hlaprFYsnDHrkb mWfw==
X-Gm-Message-State: AOAM530SA/ZZYx04R4kligNWSBSRY2Xso/XlA5tb3jrr9zT9xrIvVJ5F 6xHA9SdlYuVbUTtSm+nfmbvVhtvboi8=
X-Google-Smtp-Source: ABdhPJwX9j4vnlnOq4havdCifJLKUUeXEj8xJWrthE0Edro3BHYU2zhAjRx2Jx+XFB3REYAOBbJrdw==
X-Received: by 2002:a65:5b04:: with SMTP id y4mr12583983pgq.195.1631562575267; Mon, 13 Sep 2021 12:49:35 -0700 (PDT)
Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id on6sm5878257pjb.19.2021.09.13.12.49.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Sep 2021 12:49:34 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <BBC6AA9F-86C1-4A9C-86FD-AD77668CA9D9@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_42F7EB2A-C472-4B6B-9F33-499A86D9DC46"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Mon, 13 Sep 2021 12:49:33 -0700
In-Reply-To: <20210910200902.bic4rhyhp75bgsjz@anna.jacobs.jacobs-university.de>
Cc: Lou Berger <lberger@labn.net>, "netmod@ietf.org" <netmod@ietf.org>, Babel at IETF <babel@ietf.org>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
References: <AM7PR07MB624802516EFB174B6912C5DAA0D69@AM7PR07MB6248.eurprd07.prod.outlook.com> <20210910121430.kofyvd2q3ludm2pk@anna.jacobs.jacobs-university.de> <AM7PR07MB62482A4271AF1CA5013EB136A0D69@AM7PR07MB6248.eurprd07.prod.outlook.com> <b1b1cd18-537f-561f-dcb1-9aca41b7d3c9@labn.net> <20210910200902.bic4rhyhp75bgsjz@anna.jacobs.jacobs-university.de>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/UPGz4JhzPRqT9POPu5ovqT3IXaI>
Subject: Re: [babel] [netmod] NULL value for uint16
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: Mon, 13 Sep 2021 19:49:45 -0000

[Bringing in babel WG, instead of maintaining two threads]


Hi Juergen,


> On Sep 10, 2021, at 1:09 PM, Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> On Fri, Sep 10, 2021 at 01:40:03PM -0400, Lou Berger wrote:
> 
>> and it references an RFC that says:
>> 
>>      This is a 16-bit unsigned integer;
>>      if the data model uses zero (0) to represent NULL values for
>>      unsigned integers, the data model MAY use a different data type
>>      that allows differentiation between zero (0) and NULL.
> 
> We are talking about RFC 9046? RFC 9046 repeats this sentence several
> times but I find it difficult to infer the intended meaning. If 0 is a
> legal value, you can't have it represent "NULL" at the same time.

There are five definitions in the Babel YANG model <https://www.ietf.org/archive/id/draft-ietf-babel-yang-model-11.html> that use NULL to represent a special meaning.

With ‘babel-route-received-metric’, and ‘babel-route-calculated-metric’ values use NULL or 0 to represent that a route was NOT received. A non-zero value indicates that a route was received and subsequently advertised.

With ‘babel-expo-mcast-hello-seqno’, and ‘babel-exp-ucast-hello-seqno’ a value of NULL or 0 is used to represent that a multicast, or unicast hello packets respectively are NOT expected or processing of multicast/unicast packets is not enabled. Although not explicit stated, it also means that the sequence number cannot be a 0.

Finally, with ‘babel-ucast-hello-seqno’ a value of NULL or 0 is used to represent a unicast hello is not being sent. A non-zero value reflects the current sequence number in use for unicast hellos. Again, although not explicit, it also means that the sequence number cannot be a 0.

> 
> In YANG, we tend to not instantiate leafs that do not have a value.
> Anyway, if a YANG author wants to report a special value to indicate
> that there is no value, then you have design for it and reserve and
> set aside a special value from the number space or use a union.

This YANG model reserves the value of 0 to indicate that these leafs are not set or the particular attribute is not enabled.

Thanks.

> 
> RFC 9046 uses the same text for things like sequence numbers. Skimming
> RFC 8966, it seems sequence numbers are 16-bit integers:
> 
>   Sequence numbers (seqnos) appear in a number of Babel data
>   structures, and they are interpreted as integers modulo 2^(16).
> 
> The text in the context makes me believe they are an unsigned 16-bit
> integers. If so, there simply is no way to use 0 to indicate that a
> sequence number is absent. The problem really might be the text in RFC
> 9046.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com