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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 690251314C1 for <>; Mon, 20 Mar 2017 09:49:56 -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 Db0KX1rh_uVG for <>; Mon, 20 Mar 2017 09:49:54 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48DA81314C0 for <>; Mon, 20 Mar 2017 09:49:53 -0700 (PDT)
Received: (qmail 1897 invoked from network); 20 Mar 2017 17:43:10 +0100
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Mar 2017 17:43:10 +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: <20170314090649.GB54939@elstar.local>
Date: Mon, 20 Mar 2017 17:43:09 +0100
Cc: The IESG <>,, Dan Romascanu <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <20170314090649.GB54939@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 16:49:56 -0000

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?

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

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.

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?

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?

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.

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.

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


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