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

"Mirja Kuehlewind (IETF)" <> Mon, 20 March 2017 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A5A512951E for <>; Mon, 20 Mar 2017 13:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 95FKDf45i-Td for <>; Mon, 20 Mar 2017 13:18:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 635B412951B for <>; Mon, 20 Mar 2017 13:18:27 -0700 (PDT)
Received: (qmail 11331 invoked from network); 20 Mar 2017 21:11:43 +0100
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Mar 2017 21:11:43 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: "Mirja Kuehlewind (IETF)" <>
In-Reply-To: <20170320172731.GA33917@elstar.local>
Date: Mon, 20 Mar 2017 21:11:06 +0100
Cc: Dan Romascanu <>,, The IESG <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <20170314090649.GB54939@elstar.local> <> <20170320172731.GA33917@elstar.local>
To: Juergen Schoenwaelder <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Subject: Re: [lmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lmap-yang-11=3A_=28with_DISCUSS_and_COMMENT=29?=
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Mar 2017 20:18:31 -0000


> Am 20.03.2017 um 18:27 schrieb Juergen Schoenwaelder <>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.

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

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

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

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

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

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


> /js
>>> Am 14.03.2017 um 10:06 schrieb Juergen Schoenwaelder <>de>:
>>> On Fri, Mar 10, 2017 at 08:47:09AM -0800, Mirja Kühlewind wrote:
>>>> ----------------------------------------------------------------------
>>>> ----------------------------------------------------------------------
>>>> 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
>>>> ----------------------------------------------------------------------
>>>> ----------------------------------------------------------------------
>>>> 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.
>>> 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         <>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <>
> _______________________________________________
> lmap mailing list