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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 20 March 2017 17:28 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 D80AF1315AF; Mon, 20 Mar 2017 10:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 nQBv0hIXoFpO; Mon, 20 Mar 2017 10:28:35 -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 6F149131504; Mon, 20 Mar 2017 10:27:37 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 461AC699; Mon, 20 Mar 2017 18:27: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 N15EN_s9vR8a; Mon, 20 Mar 2017 18:27:27 +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; Mon, 20 Mar 2017 18:27:28 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B5BB20035; Mon, 20 Mar 2017 18:27:28 +0100 (CET)
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 6-aCLQuVQRE5; Mon, 20 Mar 2017 18:27:26 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B267F20033; Mon, 20 Mar 2017 18:27:26 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D12B53EEFA09; Mon, 20 Mar 2017 18:27:31 +0100 (CET)
Date: Mon, 20 Mar 2017 18:27:31 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-lmap-yang@ietf.org, Dan Romascanu <dromasca@gmail.com>, lmap-chairs@ietf.org, lmap@ietf.org
Message-ID: <20170320172731.GA33917@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, draft-ietf-lmap-yang@ietf.org, Dan Romascanu <dromasca@gmail.com>, lmap-chairs@ietf.org, lmap@ietf.org
References: <148916442967.6864.11561838065992971408.idtracker@ietfa.amsl.com> <20170314090649.GB54939@elstar.local> <0AEF216F-3B1D-46FE-96B5-38165D6C1308@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: <0AEF216F-3B1D-46FE-96B5-38165D6C1308@kuehlewind.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/m5FYV354PT3jMCXbMj5ICEBL0as>
Subject: Re: [lmap] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-iet?= =?iso-8859-1?q?f-lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?=
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: Mon, 20 Mar 2017 17:28:39 -0000

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.

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

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

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

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

/js

> 
> 
> 
> 
> > Am 14.03.2017 um 10:06 schrieb Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>de>:
> > 
> > On Fri, Mar 10, 2017 at 08:47:09AM -0800, Mirja Kühlewind wrote:
> >> 
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >> 
> >> This draft does not specify a bootstrapping process (see RFC 7594 5.1. 
> >> Bootstrapping Process) and says:
> >> "Pre-Configuration Information: This is not modeled explicitly since
> >> bootstrapping information is outside the scope of this data model."
> >> So when and where and how will this be specified?
> > 
> > There is work ongoing in NETCONF to provide different pieces for
> > bootstrapping.
> > 
> > - draft-ietf-netconf-keystore
> > 
> >  a model for managing keys
> > 
> > - draft-ietf-netconf-netconf-client-server
> > 
> >  a model for managing NETCONF client and server config
> > 
> > - draft-ietf-netconf-restconf-client-server
> > 
> >  a model for managing RESTCONF client and server config
> > 
> > - draft-ietf-netconf-ssh-client-server
> > 
> >  a model providing NETCONF over SSH config details
> > 
> > - draft-ietf-netconf-tls-client-server
> > 
> >  a model providing NETCONF over TLS config details
> > 
> > - draft-ietf-netconf-zerotouch
> > 
> >  a mechanism for loading bootstrapping information
> > 
> >> ----------------------------------------------------------------------
> >> COMMENT:
> >> ----------------------------------------------------------------------
> >> 
> >> Also it is not clear when and how to perform configuration actions. To be
> >> a fully function protocol more guidance is needed. Not sure if that is
> >> even the intention of this document but I don't see any other documents
> >> that serves this purpose in the lmap queue. (And the milesstones are not
> >> up to date and don't indicate with document maps to which milestone.)
> > 
> > When and how is up to the controller design. The fully functioning
> > protocol falls out of the YANG data model - once you have YANG data
> > model, you are ready to go. That said, there is a currently expired
> > WG document providing more details.
> > 
> > https://tools.ietf.org/html/draft-ietf-lmap-restconf-03
> > 
> > The idea here was just provide an explanation how the LMAP data model
> > works together with RESTCONF.
> > 
> > /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/>
> 

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