Re: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12

Fredrik Kers <fredrik.kers@netrounds.com> Wed, 03 May 2017 14:00 UTC

Return-Path: <fredrik.kers@netrounds.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26053127077 for <lmap@ietfa.amsl.com>; Wed, 3 May 2017 07:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netrounds-com.20150623.gappssmtp.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 SUm3K2yhdTkS for <lmap@ietfa.amsl.com>; Wed, 3 May 2017 07:00:30 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 EBB75129B52 for <lmap@ietf.org>; Wed, 3 May 2017 06:56:45 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id r190so59436986wme.1 for <lmap@ietf.org>; Wed, 03 May 2017 06:56:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netrounds-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=hBLq4n87t/989qN1a1irr6Tw7rleeXqX2cGdUF6a15Y=; b=KyXlGOFMcaqXjng8nhAYhm2kTYNrdHxI6vfotctTXoecVJQAIFT9p0SRW2GjMDcQFn wdJloekXkZEkUnu77b9kZ3u/5mfsPa6X65d77GJm1KFrt0l+E/qjpyg+JgRDbgLEUEQL etLNmnJBhXRjlCowGv4v27BIoxgHAbmbpph0Af4jJY1scJ9xHmBh/s5AudFyn2u9MlgE 1uhuno3ddg5XeEDTroophCnufvxsQ/V13ALbG753N/UDWaqmkuzP6iueseIKlbRXmX0L ElRikjw0Ty4cHn6XbNKEO/CDuQAg0rBkYyILe7/Bu9s/6dVt0S7fRXNa3SgcugBe28q1 bQMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=hBLq4n87t/989qN1a1irr6Tw7rleeXqX2cGdUF6a15Y=; b=G6v3vvMAsOO8U7K/lwYhmPmzsWVJUrcUUKidRpra5yTQlqVAFqnyUMRHzfitoXeaS4 5UduviNdFXmXuN7cNKnje2YX7fbXmhHj3TgS1b2/XGt6mxg7X2BZyGE3cLGbtXIMj8ay oHwV+T1t9/K9YsmswwVJs5hw5+NyeivWQsrr0/Brwek7AIoGXcrD47X2HebCzUypRTCF qtnaVG5Oc28WjIQTpat4TU2pSqRaVPkpEhIUMRo0QNgp5p3o0gXZKASIi3dNPljLnJK8 gZXQ1Yb0GKW2N0POuXR3UJDpr8iHB6+G0RydmPXPTlk+5hhlNTFxrpPYLLoQeSOL5E0b yAMg==
X-Gm-Message-State: AODbwcCmR6dPyj/uhfOOjylXR/KSMDkpjdRX3oNTHY7HxKq3Fu4IQ4ww zl/BvzXveDmZ2/NkCjw4qWFKrJvctw==
X-Received: by 10.28.26.82 with SMTP id a79mr270761wma.119.1493819804400; Wed, 03 May 2017 06:56:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.154.16 with HTTP; Wed, 3 May 2017 06:56:43 -0700 (PDT)
In-Reply-To: <20170503102406.GC6642@elstar.local>
References: <CAKkp-KQCaV1F0SZDW93Ljw1CKVb8ZbqE8TKo=Ytkn58WOmK4tw@mail.gmail.com> <20170503102406.GC6642@elstar.local>
From: Fredrik Kers <fredrik.kers@netrounds.com>
Date: Wed, 03 May 2017 15:56:43 +0200
Message-ID: <CAKkp-KROXUdN6QkczeGUodfSXDOd=CuyoiJm3Lc_CXOn3qgUMw@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Fredrik Kers <fredrik.kers@netrounds.com>, lmap@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c05be0eccd73a054e9f06d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/8Ib5m4TWhFFl5HwnZfgFJzTdZkE>
Subject: Re: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lmap/>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2017 14:00:41 -0000

On Wed, May 3, 2017 at 12:24 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, May 03, 2017 at 11:50:34AM +0200, Fredrik Kers wrote:
> > Hi!
> > I'm looking at aligning a project with the LMAP data model (
> > https://tools.ietf.org/html/draft-ietf-lmap-information-model-18) and
> YANG
> > model (https://tools.ietf.org/html/draft-ietf-lmap-yang-12) and have
> some
> > questions and comments.
>
> Note that the two documents have just been moved to the RFC editor
> queue (after ~3 years of development within the WG). While comments
> and questions are welcome, there likely won't be any technical changes
> soon.
>

I just saw that. Congratulations! I hope I don't ruin your day with all
these questions :)


> > First, some comments on the information model.
> >
> > 1)
> > Normally a task in computer terms means a process or a "unit of
> execution"
> > as it is described on Wikipedia (
> > https://en.wikipedia.org/wiki/Task_(computing)), while in LMAP it means
> a
> > program/executable, or a function in more abstract terms. I was confused
> > for quite some time until I understood that a task in LMAP actually
> meant.
> > I would suggest using a more common terminology, but I understand that it
> > might be a bit too late to change the name of such a central concept.
>
> I do not think task necessarily means executable in LMAP. The term
> task is used in order to stay away to some extend from implementation
> specifics.
>

No, the information model does not mention how a Task should be
implemented, so it could be in any form. However, in the YANG model the
task is actually assumed to be an executable because of the "program" leaf
with the description "The (local) program to invoke in order to execute the
task."

Anyway, my comment was not about whether a Task is realized as an
executable or not but that the term "task" in LMAP doesn't mean what you
would expect. But I understand that it's too late to change this.


> > 2)
> > The information model describes the concept of Measurement Task,
> Reporting
> > Task, Control Task, etc. (
> > https://tools.ietf.org/html/draft-ietf-lmap-information-model-18#page-9
> ),
> > and that Control Tasks can be used to configure the Schedules, Tasks etc.
> > on the MA. However it's not described what mechanism a Control Task uses
> to
> > configure the MA. The normal task input/output model only describes how
> > data flows between instances of tasks and schedules, but does not give
> any
> > way to communicate with the MA itself. How is this supposed to work?
>
> It is (a) not required to implement things via control tasks and (b)
> how control tasks do their work is and implementation detail.
>

OK. Since the concept of Control Tasks is covered in the RFC, it would be
good to clarify that the communication interface between the Control Task
and the MA is outside of the scope of the RFC.

> 3)
> > Related to this the Control Tasks, the information model in one place
> > states that "in terms of the Information Model, all Tasks have the same
> > structure", but in another place states that "Suppression has no effect
> on
> > either Controller Tasks or Controller Schedules".
> >
> > So the question is, is a Control Task (and Schedule) handled differently
> by
> > the MA compared to other types of Tasks (and Schedules)?
>
> In this particular aspect, they may be handled differently. If you,
> for example, implement an LMAP agent running behind a NAT, then there
> needs to be something that calls home to the controller. This
> something might be implemented as a control task or it might be
> implemented as part of the LMAP agent itself. If this would be
> implemented as a control task, then attempts to suppress call home
> would likely be rejected (since this would essentially mean the LMAP
> agent becomes disconnected and hence useless). There may be additional
> control tasks, e.g., a control task that clears buffered data in case
> an LMAP agent is running low on memory. Again, an implementation may
> not support suppression of such a house keeping control task.
>

I understand the reason one might want to prevent suppression of certain
Tasks, but stating that some Tasks should be treated differently without
additional information on how to identify those Tasks leaves the reader
wondering. If you think that it's up to the implementation to decide how to
identify the task, I think than it should be mentioned.


> > And now some comments on the YANG model.
> >
> > 4)
> > In the YANG model, a task can be listed in three places;
> > /lmap/capabilities/tasks/task, /lmap/tasks/task and
> > /lmap/schedules/schedule/action/task. Let's see if I understand this
> > correctly...
> >
> > * /lmap/capabilities/tasks/task lists the available tasks that the MA can
> > execute, which is not configurable from a controller but is configured
> > locally at the MA, for example in a config file or even at compile time.
> > * /lmap/tasks/task is the tasks that has been configured with some
> default
> > options and are available to be executed.
> > * /lmap/schedules/schedule/action/task pints at what task to start when
> an
> > action is fired, and provides additional options to it.
>
> Correct.
>
> > To me it's not clear why the middle step (/lmap/tasks/task) is required
> > since all the properties at that level (options and tags) can also be
> > configured in the action, except the functions list which seems weird to
> be
> > able to configure anyways (see next comment).
>
> The 'middle step' is an optimization for situations when you have many
> actions that want to share common task parameters.
>

OK.


>
> > 5)
> > In /lmap/tasks/task you can configure a list of functions for a task,
> which
> > might or might not be the same functions listed in
> > /lmap/capabilities/tasks/task. The purpose of this functions lists is not
> > crystal clear to me, but it seems wrong that you can configure functions
> > that are not included in the capabilities.
>
> I assume an implementation would reject an attempt to configure a
> function that does not apply. What is your proposal? To have this
> spelled out more clearly in the YANG model? To have some sort of a
> must constraint to express this? (I would have to think about how to
> write this.)
>

Of course you could solve it at the implementation level, but as a user of
an interface based on the YANG model I would wonder what to configure in
/lmap/tasks/task/function and why.

The /lmap/tasks/task/program leaf, which will have the same issue, has a
"nacm:default-deny-write" statement, that I assume is to prevent
configuration of it. Could something similar be done?

An alternative is to remove the "program" and "function"
(registry-grouping) completely from the /lmap/tasks/task since they already
exist in the task in the capabilities which is referenced by name.

> 6)
> > To keep the structure of the YANG model consistent all lists should be
> > wrapped in a container, e.g. move /lmap/schedules/schedule/action to
> > /lmap/schedules/schedule/actions/action. Other lists that would be
> affected
> > are "function", "option", "result", "conflict", "table" and "row". Is
> there
> > a reason for the different structure of some lists?
>
> YANG generally does not have nodes representing lists and some people
> believe such additional containers just add additional noise to the
> data encodings with little value.
>
> The reason why we have the top-level containers is because people
> found it useful to have some top-level structure (similar to the way
> we have structured the information model into several aspects); so
> these top-levels provide structure, they do not represent lists. For
> example, /lmap/agent is just a container for scalars and
> /lmap/capabilities is a container with scalars and a list.
>

OK

Regards,
Fredrik

-- 
*Fredrik Kers* | CTO
*Netrounds* | Storgatan 7 | 972 38 Luleå | Sweden | www.netrounds.com