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

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 21 January 2020 04:24 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 6DF37120045 for <babel@ietfa.amsl.com>; Mon, 20 Jan 2020 20:24:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.897
X-Spam-Level:
X-Spam-Status: No, score=-0.897 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, 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 hzOPgcRAhiCZ for <babel@ietfa.amsl.com>; Mon, 20 Jan 2020 20:24:02 -0800 (PST)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 EAB83120026 for <babel@ietf.org>; Mon, 20 Jan 2020 20:24:01 -0800 (PST)
Received: by mail-pj1-x1036.google.com with SMTP id m13so808331pjb.2 for <babel@ietf.org>; Mon, 20 Jan 2020 20:24:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=T1JW/arXuIT8x0hfxCvUNwWBuYVIZGzPFvss/BMVVkQ=; b=SIYd2rL2Hztkl/ufLEe0Zud7uC8AsSBU8VB5EpNy1jO+FJk38DNs59ur66R5N7N67b SAO1aCQQctP6H8t4ExraT1SWAokei8N7RbdNlBSV1SbvWg/D+5Y3rrmnTgXEqUOKuygT EJhcBuIt+l3gYK07ETn/hPAt4HRmKYQlbx5QGXEOORp1Cto69XdwDsDh94M2dXvZr6Qh ysMwWak/kimrvWXrsRVC4LNwVcvGn0afkH56aKV6C3WckXYMOx5dRorkZfLEtJGwuQkX AzvtrdNWDqpkXY+framraTfRWbc8WnV1JoEQgGdae2XnCaTPZmRzdcDWSd+mZkKJVRCo W6eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=T1JW/arXuIT8x0hfxCvUNwWBuYVIZGzPFvss/BMVVkQ=; b=ZaxdTtc6qtMvpQEJwJsemldf6bu/l3wEOjPdOIvegXAHk/pUr6Sryj3RP4yzYLdH1z QOYW3Xe1CuNoM5AfQnOKsk+bMp5hQwfHo5lxcQ6gMoNn8GZMWITjKLDUzwP159XThs46 G0thh4xA/Ch08zdl7Ei820fllQMZvdoa0MNQNFWGXMEjHAH7rq9L0G481J/WTmKSz/Aq yVLEuEHMbZVFWVAgIPXZmNuXaJcQNDEhCCDXnC/36flzcdhVRxx3y/rET4M+2G2ztKsj YNrxptX8P66NJO+UPdlvrpQ0MSdnr1frgDWFwglMGD9FN3nzIhczujNGIMLuJd4QFuW7 i2Xg==
X-Gm-Message-State: APjAAAX93inuQmSXRJRl7J5QiGg7AGBstT7HE9n0QnmWf5adlrsrZib/ LRxXofFgUadtQK+BaxL/n20=
X-Google-Smtp-Source: APXvYqzuchVhiQq46/0hHGH628z/B6c68VarNAnyUQKXC+PsXU87h4eOi3etk+nWbX8QlC0HXBQ2Yw==
X-Received: by 2002:a17:90a:20c4:: with SMTP id f62mr3162974pjg.70.1579580641310; Mon, 20 Jan 2020 20:24:01 -0800 (PST)
Received: from ?IPv6:2601:647:5600:5020:84a0:9bd5:34a7:f9eb? ([2601:647:5600:5020:84a0:9bd5:34a7:f9eb]) by smtp.gmail.com with ESMTPSA id v5sm40329784pfn.122.2020.01.20.20.23.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jan 2020 20:24:00 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <BCAFDF16-31C7-45C7-B42B-2E900D2A1287@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_702EE1AA-B6C9-4749-976C-2E57B15ADCA7"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 20 Jan 2020 20:23:58 -0800
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61153757B62@GAALPA1MSGUSRBF.ITServices.sbc.com>
Cc: Donald Eastlake <d3e3e3@gmail.com>, "babel@ietf.org" <babel@ietf.org>
To: "STARK, BARBARA H" <bs7652@att.com>
References: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com> <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com> <CAF4+nEGLgO2Swkd4_DMGmyygM_-jZZKCooNV4OExAR6XR0xcxA@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E61153757B62@GAALPA1MSGUSRBF.ITServices.sbc.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/l9gKLB7Txi_lFj9MQwXsLslx7Nw>
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: Tue, 21 Jan 2020 04:24:03 -0000

Hi Barbara,

Good point. What would you expect the reset action on packet log to do?

The difference between packet log and statistics from a data model is that, statistics are maintained by the data model. As such a reset causes the values in the data model to be cleared. For the packet log, all that the model does is maintain a pointer to a URL/file where the log is maintained. It does not maintain the contents of that log. A reset action on an object that is external to the model cannot be enforced by the model. All the model can do is clear the pointer, but I gather that is not what you are looking for it to do.

Cheers.

> On Jan 20, 2020, at 8:25 AM, STARK, BARBARA H <bs7652@att.com> wrote:
> 
> That would suggest we should add a reset action for the packet log. We don’t currently have one.
> Barbara
>  
> From: Donald Eastlake <d3e3e3@gmail.com> 
> 
> 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 <mailto:d3e3e3@gmail.com>
>  
>  
> On Fri, Jan 17, 2020 at 3:13 PM Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
> 
> 
> > On Jan 17, 2020, at 7:32 AM, STARK, BARBARA H <bs7652@att.com <mailto: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 <mailto:babel@ietf.org>
> > https://www.ietf.org/mailman/listinfo/babel <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_babel&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Ervar6YVPnCewTWpMGUQdvrWDl--UTRIKVyMm-SEvF4&s=DhjYNDHNRPLsBhCPPje6e653wL9I_VCvgpjEGykc0aA&e=>
> 
> Mahesh Jethanandani
> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
> 
> 
> 
> _______________________________________________
> babel mailing list
> babel@ietf.org <mailto:babel@ietf.org>
> https://www.ietf.org/mailman/listinfo/babel <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_babel&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Ervar6YVPnCewTWpMGUQdvrWDl--UTRIKVyMm-SEvF4&s=DhjYNDHNRPLsBhCPPje6e653wL9I_VCvgpjEGykc0aA&e=>