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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

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?

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?

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

Mirja




> Am 14.03.2017 um 10:06 schrieb Juergen Schoenwaelder <[e-mail]>:
> 
> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>