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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 03 May 2017 14:50 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 2F2D1129B16 for <lmap@ietfa.amsl.com>; Wed, 3 May 2017 07:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.236
X-Spam-Level:
X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 xe0rSAhGYLDM for <lmap@ietfa.amsl.com>; Wed, 3 May 2017 07:50:02 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BBD129B40 for <lmap@ietf.org>; Wed, 3 May 2017 07:47:35 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 40BD0EE0; Wed, 3 May 2017 16:47:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id YndBxhzY6ucX; Wed, 3 May 2017 16:47:34 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 May 2017 16:47:34 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C0C72005E; Wed, 3 May 2017 16:47:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9mhJ4h-Esmx8; Wed, 3 May 2017 16:47:33 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3208820053; Wed, 3 May 2017 16:47:33 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 124483F36DAE; Wed, 3 May 2017 16:47:32 +0200 (CEST)
Date: Wed, 3 May 2017 16:47:32 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Fredrik Kers <fredrik.kers@netrounds.com>
Cc: lmap@ietf.org
Message-ID: <20170503144732.GA7170@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Fredrik Kers <fredrik.kers@netrounds.com>, lmap@ietf.org
References: <CAKkp-KQCaV1F0SZDW93Ljw1CKVb8ZbqE8TKo=Ytkn58WOmK4tw@mail.gmail.com> <20170503102406.GC6642@elstar.local> <CAKkp-KROXUdN6QkczeGUodfSXDOd=CuyoiJm3Lc_CXOn3qgUMw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKkp-KROXUdN6QkczeGUodfSXDOd=CuyoiJm3Lc_CXOn3qgUMw@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/6e3pN1uRqpU8IY9kLATCEajqgy8>
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:50:05 -0000

On Wed, May 03, 2017 at 03:56:43PM +0200, Fredrik Kers wrote:
> 
> I just saw that. Congratulations! I hope I don't ruin your day with all
> these questions :)
>

People reading the documents are always welcome!
 
> > > 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.

The question always is: Is there anything unclear impacting
implementations and interoperability?
 
> > > 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.

I would not disagree with such a statement but I do not find it
essential and well it is too late for the first version of the model.

> > 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.

A controller does not configure which tasks are control tasks. The MA
implementation knows them.

> > > 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 function ties into a registry. Until we have such a registry, this
remains somewhat vague.
 
> 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?

The registry proponents would never configure a program; they would
identify a function via a registy entry and the system would have to
resolve how that maps to a program. Note that it is not mandatory to
have a program configured.

> 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.

An entry in the task list says which functions a task can provide. In
the configured task, you might subset that.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>