Re: [babel] proposed info model change

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 19 February 2021 00:19 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 342213A1AAF for <babel@ietfa.amsl.com>; Thu, 18 Feb 2021 16:19:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 i2Tv9kMv6OnI for <babel@ietfa.amsl.com>; Thu, 18 Feb 2021 16:19:17 -0800 (PST)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 4F62D3A1AAB for <babel@ietf.org>; Thu, 18 Feb 2021 16:19:17 -0800 (PST)
Received: by mail-oi1-x234.google.com with SMTP id 12so1308831oij.6 for <babel@ietf.org>; Thu, 18 Feb 2021 16:19:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Qhvxk7gV6RHQwqmamT/v9WrTWwl3RlyzUkl67fZQv8c=; b=i+6LKrrn83r2lzubb6AsDkp7AVeB2ge7lij/evpdP8uwAviGEPNXT7+0Nw1aqYQZef IVHXGz8PfkcuuWndizz9o3bMopXtN82jQaRv+EQq6eERrhwJP+ye8/PPr5N0F1FeQfSz EzcgStNRiKfN7FflED1EcoikqE87N0aPZYRZbs+0S68zuVoDPy3qo7IREX9OdHwom3b+ DTs2BfKExKj6csSB2rdJySXVDqFNAANLed+0Oi1vU6ekLKIdN4Mj3AQddjEMOBjVQeAV KW1pI+fs4FBCRiH0orIlozpN5Sl3Kwlh5z24mj6uwlOArPlNnHPyo9OCektKTzPfmSli CjJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Qhvxk7gV6RHQwqmamT/v9WrTWwl3RlyzUkl67fZQv8c=; b=jsrX/ZUUGf7NUJXVvLrf13nnpCg4CYIUK+Wq/PBHPPCso8DqmBfmlZClMfMOyop3On 7tB1n0uf7QOGkwnMwuXZF59vEUifFivjA76LdtJfzrIrDBomzL6Si0nS4Suufwuatj2J nN5xm9NElrO4v5wez0GZjKzva3O1V/6y0GAFcoDuDizvFINfFsBFU+Z8CogP8QeA2J0L 7a9uSUtZsUHI+YAFZkpLkX1FgtU0z8+NQZlndsVqe1R+eqFFSMeI9c3VxjpO1kenSDp5 csQ57KuXPmjxJiCEJzge2TECnl3injUi95nSqfVu3arZcaV2pVjl9+Jtoit4RdFK+l09 75rw==
X-Gm-Message-State: AOAM531SB8NP6edrO2k1DLSd9gbrT8ZcHWECxrPCd/IMQ4Cc1+u8BapW dp/dxU0z9paIRmHxqDBbclcnVDxvb/4=
X-Google-Smtp-Source: ABdhPJzMwnSjIK8s3yk1HpQmoj9VhcsiYofmd/MZILsYZqn9pOAtENFlaXpltRLe5JjC12GBekDkCg==
X-Received: by 2002:aca:314c:: with SMTP id x73mr4510262oix.85.1613693956727; Thu, 18 Feb 2021 16:19:16 -0800 (PST)
Received: from [192.168.45.253] ([12.200.58.29]) by smtp.gmail.com with ESMTPSA id m187sm65220oif.43.2021.02.18.16.19.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Feb 2021 16:19:16 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-072C0CFB-A788-4491-A5B3-B0220AF7D384"
Content-Transfer-Encoding: 7bit
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 18 Feb 2021 16:19:15 -0800
Message-Id: <61DF0E2F-64B2-4D7D-BB7E-39968350687E@gmail.com>
References: <DM6PR02MB69249AC774F6ED5661E1727CC3859@DM6PR02MB6924.namprd02.prod.outlook.com>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, Toke Høiland-Jørgensen <toke=40toke.dk@dmarc.ietf.org>, babel@ietf.org
In-Reply-To: <DM6PR02MB69249AC774F6ED5661E1727CC3859@DM6PR02MB6924.namprd02.prod.outlook.com>
To: "STARK, BARBARA H" <bs7652@att.com>
X-Mailer: iPhone Mail (18B121)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/GbanrJasCrnZix8Yvmn3KC-I0Yg>
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: Fri, 19 Feb 2021 00:19:20 -0000

Hi Barbara,

Yes, I am fine with dropping the last sentence in the description that has reference to the fact that it cannot be all zeros or ones. 

Thanks 

Mahesh Jethanandani 
mjethanandani@gmail.com

> On Feb 18, 2021, at 11:11 AM, STARK, BARBARA H <bs7652@att.com> wrote:
> 
> 
> The info model only defines what a single instance looks like. In TR-181 I have the choice of supporting multiple instances (of this single instance) or not at the hierarchical level above where I put the Babel objects. I’ve chosen not to, consistent with how other routing protocols are modeled in TR-181 and because it doesn’t seem particularly valuable to support multiple instances on a single device.
>  
> So I’m quite OK with the YANG model supporting just a single instance and not needing to index on the router-id.
>  
> But this brings me to my next question. Since the router-id is read-only and its value is completely controlled by normative behavior defined in RFC 8966, do we need to say anything in the info model? Can we simplify the router-id to description to just be “The router-id used by this instance of the
>       Babel protocol to identify itself.  [RFC8966] describes this as an arbitrary string of 8 octets.”  ?
>  
> Barbra
>  
> Hi Barbara,
>  
> Good question.
>  
> First a correction. Looking at the info-model, it is clear that there is support for one instance, i.e. one “router-id" on a given router at any particular time, and that there will NOT be multiple instances running on a router at the same time. I am specifically looking at the following line in the info-model.
>  
> binary                    ro babel-self-router-id;
>  
> I was therefore wrong in implying that the “router-id” acts as a key, as there is only one instance of the protocol on a given router.
>  
> If that is the case, the only thing we need from a modeling perspective is to make sure the “router-id” is valid, which is what the must statement allows us to do.
>  
> HTH. Thanks.
> 
> 
> On Feb 18, 2021, at 9:30 AM, STARK, BARBARA H <bs7652@att.com> wrote:
>  
> Hi Mahesh,
> Would this still allow the YANG model to use the router-id as a unique key?
> Barbara
>  
> 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 <bs7652@att.com> 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 <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
>  
> Mahesh Jethanandani
> mjethanandani@gmail.com
>  
> Mahesh Jethanandani
> mjethanandani@gmail.com
>  
> Mahesh Jethanandani
> mjethanandani@gmail.com
>  
>  
>  
> 
>