[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 09:53 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 D96BD1294B8 for <lmap@ietfa.amsl.com>; Wed, 3 May 2017 02:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 YOZKs8JQroUu for <lmap@ietfa.amsl.com>; Wed, 3 May 2017 02:53:07 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 D87F912894A for <lmap@ietf.org>; Wed, 3 May 2017 02:50:36 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id r190so51217828wme.1 for <lmap@ietf.org>; Wed, 03 May 2017 02:50:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netrounds-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=RX0I9OZthwM5uLpyQL05Sb6s9YdGm7i0V2HH8UmPjx0=; b=F9nBoTprVMpiRVhqyUfU8B1RyBA7mVto4HSFWxCVsjpypLqQz5otN/NsCtCMVAYgE8 SXy+GKfGr+otNmgo8b0vMgm8OUxlW+9JclPVtwVIsEugWaCfIHB3HMwYAkD4sawAQA1s pnwa66TGKezZGkQIJ8Xl3oPoyYmhbtz2xHwOKWnPS/6x4q/6X4BrWBKwtEF5QeMXpHMX bocduxDZSmXQVv6dWDJS6d++q9kQ6RIOMdwnaNaS6SrvA/AxWq4zfCaIzn8j5mAzAYS7 /vAGp3ucVOgG+9wVxDiVV/hRKlguTF+yVvVrr98J0LtAVeUwAf8A6azBg2Kjc4gQ+YOe XnrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RX0I9OZthwM5uLpyQL05Sb6s9YdGm7i0V2HH8UmPjx0=; b=Yt3G4fR2OLDkZC+GtrAt/KCL7ugRIEc+PD9uMjVsZj7kGVifGrpM1559+Tq0N93cro 1XPDZZNxhoF0oFOCKxaot5p2xu+pNTclj5zii11Dtt1WhjD7y6Kda1cpw8+s/KB8PI/Z 9gm3cxBqQwCLHe70qljBcAXiwSp+C4EZFo59rB9j0qwypYibs4efoq2bUU0L9hQKlJWq XfrOFVIRTlmYIS1ObKrjTA2fHIVB1pft5ofZsXxsTBrLp3sQet6GrUYb5P7OcUZ2M8by YiMOue7zNwlyoIcL9KcscALLPDxJavfkAG613tvX4iu0qUt/CkaIHkGuM79Kgdj8ZyaE k/bQ==
X-Gm-Message-State: AN3rC/4D4t1XUSKftV8/XLX9QtDEkb7G7FkPsSzIGRWfj036TOxixtk3 SL5i8z8c01O/iDsehOjhwJOZ9SHG31Kg
X-Received: by 10.28.213.132 with SMTP id m126mr1391590wmg.28.1493805035046; Wed, 03 May 2017 02:50:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.154.16 with HTTP; Wed, 3 May 2017 02:50:34 -0700 (PDT)
From: Fredrik Kers <fredrik.kers@netrounds.com>
Date: Wed, 3 May 2017 11:50:34 +0200
Message-ID: <CAKkp-KQCaV1F0SZDW93Ljw1CKVb8ZbqE8TKo=Ytkn58WOmK4tw@mail.gmail.com>
To: lmap@ietf.org
Content-Type: multipart/alternative; boundary=001a114695aa7a701e054e9b96a1
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/J3HQX2dDQWiBT4UiUAbGUgv4ZCU>
Subject: [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 09:53:12 -0000

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.

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.

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?

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)?



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.

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

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.

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?

Regards,
Fredrik

-- 

*Fredrik Kers* | CTO | linkedin.com/company/netrounds
<https://www.linkedin.com/company/netrounds>

<mats.nordlund@netrounds.com>

*Netrounds* | Storgatan 9 | 972 38 Luleå | Sweden | www.netrounds.com