Re: [babel] proposed info model change

David Schinazi <dschinazi.ietf@gmail.com> Sat, 13 February 2021 21:53 UTC

Return-Path: <dschinazi.ietf@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 8214B3A1192 for <babel@ietfa.amsl.com>; Sat, 13 Feb 2021 13:53:31 -0800 (PST)
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 FnuZTXq4Ng1j for <babel@ietfa.amsl.com>; Sat, 13 Feb 2021 13:53:29 -0800 (PST)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 1BF393A10E0 for <babel@ietf.org>; Sat, 13 Feb 2021 13:53:22 -0800 (PST)
Received: by mail-pl1-x631.google.com with SMTP id u11so1632651plg.13 for <babel@ietf.org>; Sat, 13 Feb 2021 13:53:22 -0800 (PST)
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=Uh9Ybzd2chnVYWJd72rYHeuPDJPUvClb+6UaxQkugHM=; b=cdUiImt8YjRRDruZbPPAczRbJmBSrOIrYfhiCqDQfVwNXapWfo/Y4myqdthmjKFSwf wSa8uhs2ho4QNWvgxfZEx0qk5pdoKEtsHdthMbLQ3R/q3t0kR7HmvJgOW2gdfY0S/Lyw a+5HV9chJbXZZfhA1N1BF/2xvsAlGbVMhS+sOlnpErond5C4KQ3rx5Ipn/BINM15jMeL h5/aT5H6PnSJ64iUsixI/yBLwsitqp9/CzrJTZjPsEodWSQAyBazTT5gSR83nHfVee6e ZGp0N22n1ZzE0hwNpM1CsIV0Px1ts2wrsTNWuPaBv+xybuBZmDMmnVqZSXdx9keJWx1G rVcw==
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=Uh9Ybzd2chnVYWJd72rYHeuPDJPUvClb+6UaxQkugHM=; b=CnwHmT1QMN1OP38ySbKphhM9Z+CfoPpDCkAFKvKOSzQBYdEIaRKhwZyKCMww+m2/4E 6G+sLKViZE+oEf0vRS7H0zWAL3Ugfxj1M/N+jDJNub/lNLv+rSxTBB8v7l3oqUGHHLn/ Jrap9wkPy4LtTwU5A8gEy3pNlPW6Baqd1nCoRm7q07MIHhtE5dB4eR/gkwwQzX8Thj0M TEGg1Up7hJcsnM9ZVoZfares42r4se7URzaHFd9g4NvNm5+YsksOJYT26w4ppXAacYJV 5yUO0T2eTMXQR4kbjUc37YsBWsjcESyQ/FJkvre1aOKjIkhxS7SrQcvnIh+tLMGSMDXj TTNA==
X-Gm-Message-State: AOAM530UxSFOJNomxprW7EqdUMrbVt1R5k5RU3619fN5tA24x5t2AcmX Bse6d8UBkA+E5/K4OejBXyGV7LEAM8MyrKEX/K4=
X-Google-Smtp-Source: ABdhPJwsK9cWRguRyGbpd1JGByHAbXXAaMcRcqboTfVbp/5NZhnFH11WzTIcCw9QLC+BeKis2LT7YgPszmlUc8ETWnQ=
X-Received: by 2002:a17:90b:2382:: with SMTP id mr2mr3487371pjb.190.1613253199822; Sat, 13 Feb 2021 13:53:19 -0800 (PST)
MIME-Version: 1.0
References: <DM6PR02MB6924E3E2DD5568E247859E18C38C9@DM6PR02MB6924.namprd02.prod.outlook.com> <87blcqpau7.fsf@toke.dk> <E5F69D0C-7130-42D3-9080-C2EE5786D917@gmail.com> <878s7up8n0.fsf@toke.dk> <CAPDSy+6YWPr81uKHrWYoY=TZ0A18A_Ui3=CyLP=1K-ezwmgF-g@mail.gmail.com> <DBBE09E1-F407-4B5A-A096-669E74F25FB4@gmail.com> <DM6PR02MB69249CEAAB32A391274A8ED3C38B9@DM6PR02MB6924.namprd02.prod.outlook.com>
In-Reply-To: <DM6PR02MB69249CEAAB32A391274A8ED3C38B9@DM6PR02MB6924.namprd02.prod.outlook.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Sat, 13 Feb 2021 13:53:08 -0800
Message-ID: <CAPDSy+4uor1P_HiKGEMOTihq+0gb_wuQU21shpgDmVQHNnfv3w@mail.gmail.com>
To: "STARK, BARBARA H" <bs7652@att.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, Toke Høiland-Jørgensen <toke=40toke.dk@dmarc.ietf.org>, "babel@ietf.org" <babel@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e8829f05bb3ec762"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/RON8-DfSkI5gFh5zIwuoOT_NcMc>
Subject: Re: [babel] proposed info model change
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: Sat, 13 Feb 2021 21:53:38 -0000

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 <bs7652@att.com> 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 <mjethanandani@gmail.com>
> *Sent:* Thursday, February 11, 2021 11:56 PM
> *To:* David Schinazi <dschinazi.ietf@gmail.com>
> *Cc:* Toke Høiland-Jørgensen <toke=40toke.dk@dmarc.ietf.org>; STARK,
> BARBARA H <bs7652@att.com>; babel@ietf.org
> *Subject:* Re: [babel] proposed info model change
>
>
>
> Hi David,
>
>
>
> On Feb 11, 2021, at 7:09 PM, David Schinazi <dschinazi.ietf@gmail.com>
> 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 <toke=
> 40toke.dk@dmarc.ietf.org> wrote:
>
> Mahesh Jethanandani <mjethanandani@gmail.com> 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
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/babel__;!!BhdT!3HjRHugiRwRBmxjH7eRjssZBgzbBm5snhzyvT2apBtscBdcCqo2THFENFjzZoA$>
>
>
>
> Mahesh Jethanandani
>
> mjethanandani@gmail.com
>
>
>
>
>
>
>
>
>