Re: [babel] proposed info model change

Mahesh Jethanandani <> Thu, 18 February 2021 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 138733A14A5 for <>; Thu, 18 Feb 2021 09:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 36_tvzXW6QdP for <>; Thu, 18 Feb 2021 09:26:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5A293A14AD for <>; Thu, 18 Feb 2021 09:26:10 -0800 (PST)
Received: by with SMTP id e9so1921498pjj.0 for <>; Thu, 18 Feb 2021 09:26:10 -0800 (PST)
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=w3ozZA95kk7Qmd3b7FfmVzLzkLs0ZfgqdsL4hAcQ1DA=; b=nlwmmP012+wWDSyVQ51MUVNY4QyHM0KCKkkeuDiOx8oae68JT0FbW2nCilLrSzxRpT a2ogLm/7S8uPhWybVeG/tJ1kyYo3GsPrRH2mMMYeKPAHpGnW8dduU+3dF+evMbsY1pkA wUhh3ImOsAbq5tQPWg1GyBY08ypjJpaye9be/zoYQpRAzsT/gu9q5pwOBfmErzJOVq0R ltbkQCF/wo6u9Vb1Lxy9BSmXNQ8CtQ4KBFKF2rRtWI3XeTaYTG+/JOqzFZFmCzwJ6ADW 1Draa1eY6Dwqj75BpbHa+8tPdVBro0mhcC7kv8eRzMnlp13fWnvNTI2HwswLitBbUsA5 ZDow==
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=w3ozZA95kk7Qmd3b7FfmVzLzkLs0ZfgqdsL4hAcQ1DA=; b=TolopzlfhAMr28nTM40yblNFeeUK1mEPYrk6FacxLkUVgKGnxmsYjhJIESF7ohRy7u tIhfYBmNsUO9OsrPftxn8lnKPLWH0REYxBp83CjBHBaIsb4+iRMYbog0ILtlSXYCltKH /kYam1EdX9MNyRZMhNRfTbtufNLEpvXMHBOKGiKSxhWZarwzplisQYmDqtzBjT79M4hM /oeVYBQ9OOpgptsI5tp44wqOropK0p39QOgP4eXVEVU3cjES54prT6RYyf/VGXj9R+gq +bLBVlilPPw7rEt9IwxNgtCHdEHYMpzGm1Z5yb8PiBTmApVifOso3EJhQ6kBdYoP1nVX fP4w==
X-Gm-Message-State: AOAM533qVWf6Qbf/FO4dQkAqJUblsB+MyP47uCGBxPoyuWJ9t4PP5hs9 mgwL5DCQtrVEu4++yE1KYjUSb1eG5cu3SA==
X-Google-Smtp-Source: ABdhPJy/n/nG6F2QeKIpX50pnxGhMIIoz3+KAfPDtkWi7xbyDPepduAVYNOPcsWJb/ywCGPPA1gIFg==
X-Received: by 2002:a17:90a:778b:: with SMTP id v11mr4818043pjk.61.1613669170303; Thu, 18 Feb 2021 09:26:10 -0800 (PST)
Received: from ?IPv6:2601:647:5600:5020:9559:eaee:bbd7:a39e? ([2601:647:5600:5020:9559:eaee:bbd7:a39e]) by with ESMTPSA id f3sm6520290pfe.25.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2021 09:26:09 -0800 (PST)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CDCD3D81-A6BC-4440-A554-96E194308A04"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 18 Feb 2021 09:26:08 -0800
In-Reply-To: <>
Cc: David Schinazi <>, =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= <>, "" <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [babel] proposed info model change
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: Thu, 18 Feb 2021 17:26:13 -0000

Hi Barbara,

Thanks for circling back on the question of router-id and its impact on the YANG model.

Based on the discourse on this thread, it is clear that the “router-id” has meaning when the protocol is enabled. The YANG model can therefore add a conditional statement, i.e. a must statement, that allows the read of the “router-id” only if the protocol is enabled via the “enable” flag. 

Is the WG acceptable of the change?

> On Feb 17, 2021, at 1:17 PM, STARK, BARBARA H <> wrote:
> I’d like to circle back around to Mahesh, then, to see if this change is really a good idea from his perspective. If we do this change, then it means an implementation could start with an all-zero router-id before its enabled and then generate a “real” router-id when enabled. Which was what the original all-zero prohibition was trying to prevent. If this is acceptable for YANG (to have a changing router-id), then I see no need for any prohibition in the info model (because the protocol spec will ensure uniqueness when the “real” router-id is generated).  If not acceptable, then it seems to me we need to keep the current info model all-zero prohibition.
> Barbara
> Ah I see, thanks for the explanation! I'm fine with the change then.
> David
> On Fri, Feb 12, 2021 at 6:43 AM STARK, BARBARA H < <>> wrote:
> Just to be clear ...
> An enabled Babel instance (that is sending and receiving Babel packets) already has a requirement for unique non-zero router-id. Where we were having a problem was with not-enabled Babel instances that weren’t actively running the protocol (had maybe just been installed). I think it was babeld that was just using a default of all zeroes until it was enabled; at which time it generated its unique router-id. With this not-enabled “zero” default, the possibility exists for multiple not-enabled Babel instances to be defaulted to zero, which would lead to YANG having a problem with having a unique router-id to identify them by.
> The fact that the Babel protocol forbids zero valued router-ids doesn’t mean not-enabled instances can’t have that as a default; and it doesn’t prevent there from being multiple not-enabled instances with a default value.
> TR-181 doesn’t have a problem with this, because it uses a unique key distinct from the router-id. The Babel protocol spec already has what it needs to make sure the router-id for enabled instances are unique (and the data/info model doesn’t need to be involved in policing this). So this really is just about making sure the language is suitable to ensure YANG can use this parameter as a unique key, without putting constraints on the protocol. If YANG were fine with a Babel instance that started with router-id zero and then changed to something else once the protocol started running, then zero wouldn’t be a problem if there is just a single instance with that zero value.
> Barbara
> From: Mahesh Jethanandani < <>> 
> Sent: Thursday, February 11, 2021 11:56 PM
> To: David Schinazi < <>>
> Cc: Toke Høiland-Jørgensen < <>>; STARK, BARBARA H < <>>; <>
> Subject: Re: [babel] proposed info model change
> Hi David,
> On Feb 11, 2021, at 7:09 PM, David Schinazi < <>> wrote:
> We banned all-zeroes and all-ones between draft-ietf-babel-rfc6126bis-00 and draft-ietf-babel-rfc6126bis-01. If memory serves, the idea was to reserve them for future extensibility. Also, banning all-zeroes allows using that as a sentinel value in software.
> Adding the uniqueness requirement sounds good to me, but removing the ban on all-zeroes/all-ones could lead to problems. If the core protocol doesn't allow it, why should the informational model allow it?
> If the protocol banned it, that is a different question, and info model can reflect that. I just wanted to point out that it is not because of the data model.
> Cheers.
> David
> On Thu, Feb 11, 2021 at 2:00 PM Toke Høiland-Jørgensen < <>> wrote:
> Mahesh Jethanandani < <>> writes:
> > Hi Toke,
> >
> > The rational has to do with what a data model like YANG does with
> > router-id. To it the router-id is a key, in the form of a string. That
> > string has to be unique. YANG does not prevent it being a string of
> > zeros or ones, provided that string is unique. Thus the dropping of
> > the "MUST NOT” and the addition of “MUST”.
> Right. I seem to recall there being some other reason why it shouldn't
> be 0, but can't find the discussion now, and looking at the code that
> doesn't seem to care. So no objection from me I guess :)
> -Toke
> _______________________________________________
> babel mailing list
> <>
> <;!!BhdT!3HjRHugiRwRBmxjH7eRjssZBgzbBm5snhzyvT2apBtscBdcCqo2THFENFjzZoA$>
> Mahesh Jethanandani
> <>
Mahesh Jethanandani