Re: [babel] info and data models -- feedback requested

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 17 January 2020 20:13 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 C041D12087F for <babel@ietfa.amsl.com>; Fri, 17 Jan 2020 12:13:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 P9mNTRmpPL8E for <babel@ietfa.amsl.com>; Fri, 17 Jan 2020 12:13:18 -0800 (PST)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 EAB3E12010E for <babel@ietf.org>; Fri, 17 Jan 2020 12:13:17 -0800 (PST)
Received: by mail-pg1-x52b.google.com with SMTP id b137so12178278pga.6 for <babel@ietf.org>; Fri, 17 Jan 2020 12:13:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ti9Co/djth4WCbJuataZpLRkNLcVqmiflkMKrHW+C8M=; b=PI3Yr7bhm/RWzu8CgJtbnXH5PMwheOtNA3NDAiOLYIAa/OaPCQ8d3B6FpqWdCyZC09 miOGlEcGJKIWgwzixr9weIa38HRVpYIBryCK3uy2qD49C+ulxdEUO/PoBd/A4Fm/7gZy kiSQkC1xvuMRSiDr0r1zRtcybWSMRD3jquZvR8jIiJVc+fUD5m5z17Op32pVAd89+dSE z3HQIr3jY0J+6fDEDiEmTu8GyRZ0WMquPJ/5rUufXa2PV77jQkq9bBFTwAU6vUkd2NDZ FqkoINRKW7Vj7wpFEwH/IAsR/BzZHJpjVvXVjRFF2rkrjE8XAPZHpthnp5392mWrg85K bzWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ti9Co/djth4WCbJuataZpLRkNLcVqmiflkMKrHW+C8M=; b=BgRHmbLt5m9n6u2deUAdu14MS0tAxHPo7jWcDGjblUkokaxOvmlT/qxaQ85czXE1JF TaYE2lT8RpgMg7r9CkWGwiaURM1vliOCrF02QdQc64HlSTaCUS89tRuwSgMEZgGBb/3k JnXlTH+e4hJp/jZRzxqNaLFYO627C7vnkLpyWYXgaDpvldMKeIoj8IN8InFi3I44yu5e YtCC65sZj7X0dHEeuE9A4sscsYxXBCwTFdrQveP3WgxiANRyxpdYsQsuF/PmKQp8FW/q lBLwjlsbDfuEqzsxEeQv9mNilWp9yfpjFs10jSSbq8KF09lNbnWp3kWvnlEGaHcd+Rex I/Fw==
X-Gm-Message-State: APjAAAVMGZzDZ9zqok4xrRh7e9ECTgo7Y1HTP7a92HOrwIhjigmQU5is EiJhcxf3A50xH0/8scTaePI=
X-Google-Smtp-Source: APXvYqyksDHfrSd5UK/QEZPnlNRpZ+uDSmaWqOSHEKEAul1d9uwDhugvrnGhJ9JirEbv7Yu/7y3Dkg==
X-Received: by 2002:aa7:8299:: with SMTP id s25mr4511353pfm.261.1579291997372; Fri, 17 Jan 2020 12:13:17 -0800 (PST)
Received: from [10.33.123.108] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id 133sm30256845pfy.14.2020.01.17.12.13.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jan 2020 12:13:16 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com>
Date: Fri, 17 Jan 2020 12:13:15 -0800
Cc: "babel@ietf.org" <babel@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com>
References: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com>
To: "STARK, BARBARA H" <bs7652@att.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/qq5TiOnwjambFQSRvKPOMmhvXrg>
Subject: Re: [babel] info and data models -- feedback requested
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, 17 Jan 2020 20:13:23 -0000


> On Jan 17, 2020, at 7:32 AM, STARK, BARBARA H <bs7652@att.com> wrote:
> 
> There are 2 items related to the info/data models that have been swirling around in my head over the past month. 
> 
> 1. Since the most recent drafts of rfc6126bis now have 2 examples of initial interval settings (for cases where fast convergence is desired, or where slow convergence is acceptable and less chattiness is desired), I don't like that we have no means for the user to express what their preference is around this (in case an implementation could support both cases). Should we have something at the top level of the model like:
> boolean                rw converge-fast;
> 
>   converge-fast:  Indicates whether the user wants the network to converge 
>      quickly (which will cause Babel messages to be sent more frequently), or
>      prefers fewer Babel messages with slower time to convergence.  Fast
>      convergence is desired if "true". An implementation MAY choose to expose
>      this parameter as read-only ("ro").
> 
> 2. In BBF, I got a comment related to babel-stats-enable and babel-packet-log-enable. It's unspecified as to whether previous data is discarded when the stats or log are enabled, or the new log entries are appended / existing counts incremented. I tend to agree that the lack of a statement will lead to inconsistency, and would prefer consistent behavior. Mahesh and I had a brief exchange where we disagreed on what the preferred behavior should be -- which suggests there is definitely a strong likelihood of different implementations choosing different behavior in the absence of guidance.

And to clarify the disagreement between Barbara and I was …

The Babel information and data models define a boolean flag that enables/disables the collection of statistics. The Babel data model in addition has an ‘action’ YANG statement defined to clear the statistics being collected. Barbara’s assumption with enabling the boolean flag was that it would implicitly clear all the statistics. But the data model with a separate ‘action’ statement requires it to be called explicitly to clear the statistics. 

Unfortunately, there isn’t a way in YANG to invoke the calling of an ‘action’ statement when a certain attribute value toggles. Implementations can choose to make it implicit by including the call to the ‘action’ statement as part of enabling statistics. But it is not something YANG can enforce.

So the question is - should the information model require that enabling of statistics collection also clear the statistics (even if the YANG model cannot enforce it) or leave it to implementations to decide/enforce?

Cheers.

> 
> I realize we're past last call. But I think these are important.
> 
> Barbara
> 
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
mjethanandani@gmail.com