Re: [lmap] Mirja Kühlewind's Discuss on draft-ietf-lmap-yang-11: (with DISCUSS and COMMENT)

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 21 March 2017 06:46 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 62B66129556; Mon, 20 Mar 2017 23:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 SB5H5KFSCP1c; Mon, 20 Mar 2017 23:46:39 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB63129551; Mon, 20 Mar 2017 23:46:38 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3C6E1714; Tue, 21 Mar 2017 07:46:36 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5yCIXATJ7JVF; Tue, 21 Mar 2017 07:46:34 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Mar 2017 07:46:34 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B42020038; Tue, 21 Mar 2017 07:46:34 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 18rUJ8HjIlS1; Tue, 21 Mar 2017 07:46:33 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D954920036; Tue, 21 Mar 2017 07:46:32 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 13CC03EF0388; Tue, 21 Mar 2017 07:46:36 +0100 (CET)
Date: Tue, 21 Mar 2017 07:46:36 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Cc: Dan Romascanu <dromasca@gmail.com>, lmap-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-lmap-yang@ietf.org, lmap@ietf.org
Message-ID: <20170321064636.GA34900@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Dan Romascanu <dromasca@gmail.com>, lmap-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-lmap-yang@ietf.org, lmap@ietf.org
References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net> <20170320172731.GA33917@elstar.local> <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <2A9728CD-7ACA-4D49-A754-EC7A06070963@kuehlewind.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/hQhTvxFLbZM1xj6yz7QGiyywdK4>
Subject: Re: [lmap] Mirja Kühlewind's Discuss on draft-ietf-lmap-yang-11: (with DISCUSS and COMMENT)
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: Tue, 21 Mar 2017 06:46:43 -0000

On Mon, Mar 20, 2017 at 09:11:06PM +0100, Mirja Kuehlewind (IETF) wrote:
> Hi!
> 
> > Am 20.03.2017 um 18:27 schrieb Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>:
> > 
> > On Mon, Mar 20, 2017 at 05:43:09PM +0100, Mirja Kuehlewind (IETF) wrote:
> >> Hi Jürgen,
> >> 
> >> I’ve read draft-ietf-lmap-information-model first and then this draft, and I was just left with a number of open questions. The simple case where a controller sends a config, the MA does the measurement and send the results to a collector is clear but draft-ietf-lmap-information-model indicates that this is supposed to cover more complex scenarios including more feedback to the controller and things like requesting capabilities.
> >> 
> >> Starting from draft-ietf-lmap-information-model: maybe you can further comment on how the following parts of the information model is covered by the yang model? Thanks!
> >> 
> >> Section 3.9 of draft-ietf-lmap-information-model:
> >> "Tasks can be
> >>  Measurement Tasks (i.e., those Tasks actually performing some type of
> >>  passive or active measurement) or any other scheduled activity
> >>  performed by the MA such as transferring information to or from the
> >>  Controller and Collectors.  Other examples of Tasks may include data
> >>  manipulation or processing Tasks conducted on the MA.“
> >> What „other scheduled activities“? Where are those defined, which information should be transferred, when should they be performed, who decides that, and what’s the purpose here? Also which data should be manipulated or what other processing tasks do you need?
> > 
> > Schedules invoke Actions that execute Tasks. Some tasks may be
> > measurement tasks, other tasks may do other things - neither the
> > information model nor the data model defines the tasks. The mapping of
> > the information model to the data model is explained in the list in
> > section 3. I do not see what really is missing or what could be
> > unclear. Implementations may use tasks for reporting, implementations
> > may use tasks for house keeping, implementations may use tasks for
> > aggregation.
> > 
> >> Also
> >> "The Task Configuration will include a local short name for reference
> >>  by a Schedule.  Task Configurations may also refer to registry
> >>  entries as described above.  In addition the Task can be configured
> >>  through a set of configuration Options.  The nature and number of
> >>  these Options will depend upon the Task. „
> >> Can you give an example for an configuration task? Why is an configuration option not sufficient?
> > 
> > There are no configuration tasks. Task Configuration refers to the
> > configuration of a task, i.e., a configured task.
> > 
> >> To be honest, I also not fully clear why you need a reporting task because what you need is to configure when the reporting should be done. If that is implemented in the same scheduler than the measurement tasks is an implementation detail and does not need to part of the information model. If it would not be part of the information model than it of course would also not need to be discussed in the yang model. However, as it is I think it would need more guidance when those task should be generated and added to the schedule.
> > 
> > The WG went through a long process to arrive at this solution. I don't
> > see what is wrong with it. You want to schedule measurements, you also
> > want to schedule the reporting. Treating both as scheduled tasks makes
> > the model simpler. Which tasks you want to configure and schedule
> > surely depends on the capabilities of an implementation and the
> > measurement objectives. I do not think we can provide much guidance on
> > this in the information model.
> 
> So I guess all the magic is now hidden in the capabilities. I saw capabilities only as something that describes a measurement, but you say you can also describe other tasks like reporting here. However, including reporting and „other tasks“ in the capabilities, makes it even harder to implement a controller, especially when the controller controls multiple different MAs. Anyway, this connection was missing for me. Maybe that could be make clearer.
>

The I-D says:

   5.  Capability and Status Information.  Information on the general
       status and capabilities of the MA.  For example, the set of
       measurements that are supported on the device.

And then it says a bit further down in the document:

   Tasks can implement a variety of different functions.  While in terms
   of the Information Model, all Tasks have the same structure, it can
   help conceptually to think of different Task categories:

   1.  Measurement Tasks measure some aspect of network performance or
       traffic.  They may also capture contextual information from the
       MA device or network interfaces such as the device type or
       interface speed.

   2.  Data Transfer Tasks support the communication with a Controller
       and Collectors:

       A.  Reporting Tasks report the results of Measurement Tasks to
           Collectors

       B.  Control Task(s) implement the Control Protocol and
           communicate with the Controller.

   3.  Data Analysis Tasks can exist to analyse data from other
       Measurement Tasks locally on the MA

   4.  Data Management Tasks may exist to clean-up, filter or compress
       data on the MA such as Measurement Task results

> >> In section 3.11.7
> >> " The ma-controller-lost-obj indicates that connectivity to
> >>  the controller has been lost.  This is determined by a timer started
> >>  after each successful contact with a controller.  When the timer
> >>  reaches the controller-timeout (measured in seconds), an ma-
> >>  controller-lost-obj event is generated.“
> >> Is there an assumption that the controller should frequently contact the MA, even if there is no config data to send? What’s the right time frame here?
> > 
> > The requirement was to ensure that an MA that is getting disconnected
> > from its controller should at some time have a chance to stop its
> > activities. This seems reasonable to me. In case the MA is behind a
> > NAT (not that unusal), you typically have to call home to let the
> > controller update the instructions. How frequently this happens is a
> > deployment decision.
> 
> If the MA is behind a NAT, the MA needs to know this and the MA anyway has to connect to the controller. I guess that can be an initial configuration but I guess the MA would also need to expose this to the controller, as a capability…?
> 

I do not understand your question. And I am not sure what you trying
to get at with this.

> >> In section 3.11.8
> >> "The ma-controller-connected-obj indicates that
> >>  connectivity to the controller has been established again after it
> >>  was lost.“
> >> How is connectivity (re-)established? By the MA or by the controller? What does connectivity even mean here? I guess the controller and MA will not have a standing transport connection. It’s rather the controller opens a connection pushes a config and closes the connection, no? An then MA does whatever is configured to do. Why do you need to maintain connectivity?
> > 
> > See above. We want to be able to shutdown MAs when their controller
> > disappears. Furthermore, MAs may be behind NATs and in this case they
> > have to initiate the connection, not the controller.
> 
> The question was here more, how does the controller know that and how often is has to connect to the client? Capabilities?
>

   ma-config-controller-timeout:       A timer is started after each
                                       successful contact with a
                                       controller.  When the timer
                                       reaches the controller-timeout
                                       (measured in seconds), an event
                                       is raised indicating that
                                       connectivity to the controller
                                       has been lost (see ma-controller-
                                       lost-obj).

Obvisouly, if you do not want to generate a controller-timeout event,
the controller should make sure the value of this object and the
connection strategy are reasonably aligned.

> >> And 3.5:
> >> "The MA will hold Capability Information that can be retrieved by a
> >>  Controller.  Capabilities include the device interface details
> >>  available to Measurement Tasks as well as the set of Measurement
> >>  Tasks/Roles (specified by registry entries) that are actually
> >>  installed or available on the MA.  Status information includes the
> >>  times that operations were last performed such as contacting the
> >>  Controller or producing Reports.“
> >> When and why will they be retrieved by the controller? How can the controller indicate to the MA to send this information and which? What will the controller do with this information? Also note that Status information is not the same than capabilities. This sounds more like an interactive protocol and not just pushing a config onto a new device.
> >> 
> > 
> > The controller retrieves this information when he likes to retrieve
> > this information. Typically, upon first contact, you like to figure
> > out what an MA can do before sending down configuration. Status
> > information may help the controller to debug problems or to keep basic
> > statistics (percentage of failed measurement execution over time).
> > 
> > I do not know what makes an 'interactive protocol' for you.
> 
> I was thinking about an interactive protocol because if all the magic is hidden in the capabilities, than there seem to be a fixed pattern, where the controller first has to request the capabilities, then the MA sends them, and then the controller sends the actual measurement config. If that’s the envisioned workflow, it would be good to say it somewhere.
> 

Perhaps you want to read of RFC 7594 which has more details about the
overall framework. In general, I find reading capabilities first
before you attempt to use functionality a pretty common concept.

> > But yes, you
> > access the YANG model either via RESTCONF (with the usual HTTP methods)
> > or via NETCONF (with the usual NETCONF operations).
> > 
> >> These are all comments on draft-ietf-lmap-information-model but I was hoping to find answers to these question in the yang model because that the actual implementation of the protocol.
> > 
> > It is a data model. The protocol primitives are in the RESTCONF /
> > NETCONF protocols. There is a separation of protocol aspects from the
> > data modeling aspects which seems to be confusing to you (but which we
> > have done for decades in the network management space).
> 
> I unterstand this separation but the way you implemented this with having everything as a task in a scheduler blurs the line. With this patter you can in theory describe every (interactive) protocol without actually describing the interactions.
> 

Sorry, I do not understand your comment.

> >> Now I also looked at draft-ietf-lmap-restconf-03 which doesn’t not provide a whole lot of additional information and the part I was actually interested in says the following:
> >> 
> >> "5.  RESTCONF Configuration for LMAP
> >> 
> >> 
> >>  XXX: This section should explain how an LMAP implementation needs to
> >>  be configured to make use of the call-home mechanism and how report
> >>  tasks refer to the configuration (if any standardized) needed to
> >>  obtain the necessary credentials to report results.  This needs to be
> >>  worked through in detail.“
> >> 
> > 
> > This section was supposed to describe how you configure RESTCONF such
> > that it works for an MA. This section was not intended to explain how
> > you may use RESTCONF to read/write configuration and reports. The way
> > we abstract protocol operations from data models seems to be new to
> > you. You seem to be searching for a concrete protocol document saying
> > if you are in state X send Y and if you receive Z do A. We do not have
> > this. With RESTCONF, everything translates into a collection of
> > resources you can GET/POST/PUT/PATCH/DELETE and the order in which a
> > controller manipulates the resources is up to the implementation of
> > the controller. (Slightly simplifying here, there is a notion of
> > validity that YANG requires but lets not go there.)
> 
> As said above, I understand the pattern restconf is using but you seem to go slightly beyond this, e.g. assuming a certain pattern where capabilities are retrieved first without every talking about this assumption.

If you want, you can write a controller that does not care about
capabilities but then it will likely often have to deal with
failures.

> I think further clarifying what capabilities are, could help; not sure in which document that should actually be done.

I do not see this need. I do not understand what your concern is.

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