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

Donald Eastlake <d3e3e3@gmail.com> Sat, 18 January 2020 21:09 UTC

Return-Path: <d3e3e3@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 E800D120019 for <babel@ietfa.amsl.com>; Sat, 18 Jan 2020 13:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.748
X-Spam-Level:
X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 RGZiHa7W4XB8 for <babel@ietfa.amsl.com>; Sat, 18 Jan 2020 13:09:41 -0800 (PST)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 43A8812008B for <babel@ietf.org>; Sat, 18 Jan 2020 13:09:41 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id n21so29702292ioo.10 for <babel@ietf.org>; Sat, 18 Jan 2020 13:09:41 -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=SWL3wld0qAWKOSFjSu5n6vxD5+u/iUPursshFxHvEWI=; b=siaft5ETBUpCCcDkFnWZ9+bqEhq7LiQrkp0UxG8auZkUXoAvt6+XsQFeNC73gqaP0g /M7626nVxTj6nWLEbhkOBkn89mwmrQBpyVBDpEL8psvkKjHJIKplJvnYHFkgDy5kxDmC JRHh0umSQ0QMmMrNJkvmdkr1DOQUj+Aea8+ZWL9SRgLkA0CDd9jGkx/e/4chEQcpMqGP nrDqZrcbB5aV4/1xGx/KrrCifIa3zCrDzK5NKkUbmrwnX94CiSGdLjoJwjqazf7klNhm BshQ+iZvAVK1gFUyzUa3+fU57Kk1Wf8gUW+q18cpRPu8iZZluDP+SqIXWVdkdBfSeI4U TT1g==
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=SWL3wld0qAWKOSFjSu5n6vxD5+u/iUPursshFxHvEWI=; b=GcD+TcLF8i3CCDXhaYjfI+8BeuAnTzqxCZzlpZ/OKbFYDu+hxdlOWksLLnRitsD/Ko x/OVhUg/Sma2Au4KBHVXJa5faRX9Rx4ZVmsU8Ma2W76rdHvgCzEW5pTeA4J8EPB8eRJ6 PNCAqmh8CABJWMxl6EshT3njlaiD4EOKCDGshHVDKEEZw/PxZ0qUOUKKv0MkB3Eoa0cg oYzBMWImV/a+6VAY25wmAoYjGi8IRGxm3vSic0tab/RR7jpROfxsvBU5E+sWzFFS/Fes 0sziJSw9F3rZTczMSYhX4c4SIeW9+DPQiPzLS1MbSpErrbJZZZoR6PZ6eb/4vjy5K2Zt TAfg==
X-Gm-Message-State: APjAAAWoMU/01aKesmpgMvX1ifV2w1JA251phQU0YoDMRo6knejoa/W9 7BvbGq/pwMSztEHq4wjQlkHWnN7Yvcfv+a+xp0E=
X-Google-Smtp-Source: APXvYqxN7wmgnnnttAoM8x4hDSYTuDpONIbMwAUyVs5bJpdTRAs+dmS0BUo4xVRyDsdgiWYqdQVMzGB+GZpVwpCakug=
X-Received: by 2002:a02:778d:: with SMTP id g135mr39393195jac.115.1579381780591; Sat, 18 Jan 2020 13:09:40 -0800 (PST)
MIME-Version: 1.0
References: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com> <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com>
In-Reply-To: <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sat, 18 Jan 2020 16:09:29 -0500
Message-ID: <CAF4+nEGLgO2Swkd4_DMGmyygM_-jZZKCooNV4OExAR6XR0xcxA@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: "STARK, BARBARA H" <bs7652@att.com>, "babel@ietf.org" <babel@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ff3730059c707930"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/S_MXGBCY0svQUgXbs5PIVd88TpQ>
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: Sat, 18 Jan 2020 21:09:43 -0000

Hi Mahesh and Barbara,

Speaking just as a WG member, it seems to me more flexible for the clearing
of statistics and the enablement of statistics to be separate actions. You
can always do both if that's wht you want.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com


On Fri, Jan 17, 2020 at 3:13 PM Mahesh Jethanandani <mjethanandani@gmail.com>
wrote:

>
>
> > 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
>
>
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>