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

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 10 Mar 2017 08:47:09 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-lmap-yang-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 14 Mar 2017 10:06:49 +0100

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

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

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 20 Mar 2017 12:01:19 -0400

Hi Mirja,

Per our telechat discussion, could you provide clarification about what further information you need to be able to clear?

Thanks,
Alissa

> On Mar 14, 2017, at 5:06 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 20 Mar 2017 17:43:09 +0100

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 <[email-masked]>:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Mar 2017 18:27:31 +0100

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

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

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.

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

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

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.

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

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

>    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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 20 Mar 2017 21:11:06 +0100

Hi!

> Am 20.03.2017 um 18:27 schrieb Juergen Schoenwaelder <[email-masked]>:
> 

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.

> controller update the instructions. How frequently this happens is a

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

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

> 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

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.

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

Mirja

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Mar 2017 07:46:36 +0100

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

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

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

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

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

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

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.

> 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) protoco…

Sorry, I do not understand your comment.

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

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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 21 Mar 2017 09:11:09 +0100

Hi Jürgen,

thanks for you replies. I went back an had another look at the framework document which answered some of my questions. I guess the minimum you can do is to make the reference to RFC7594 normative (as well as the reference to I-D.ietf-lmap-information-model as Benoit mentioned in this comment). I guess without trying to implement it, I will not be able to figure out if there is anything missing or if I’m missing something and as such I will clear my discuss now.

I still think that it could be good to give some further guidance on how connectivity is established. Something like, in most cases the controller will connect the MA and the controller should make sure that it reconnects frequently based on the timeout configuration of the MA. If the MA e.g. is behind a NAT, the MA must establish the initial connection and try to reconnect when the timeout expires. Btw. is it enough to open a transport connection or do you mean by checking connectivity that there also should be some data transmitted to ensure that the controller is no only reachable but also active?

Mirja

> Am 21.03.2017 um 07:46 schrieb Juergen Schoenwaelder <[email-masked]>:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Mar 2017 12:55:22 +0100

> thanks for you replies. I went back an had another look at the framework document which answered some of my questions. I guess the minimum you can do is to make the reference to RFC7594 normative (…

To me, it feels a bit strange to make RFC 7594 normative but if there
is IESG consensus that RFC 7594 should be normative I will implement
the change and hold my breath.
 
> I still think that it could be good to give some further guidance on how connectivity is established. Something like, in most cases the controller will connect the MA and the controller should make…

Depends to some extend on the protocol used. I think it is more than a
TCP connection, you also need to successfully authenticate (I
think). And then some protocols immediately become chatty - NETCONF
has a <hello> exchange, with RESTCONF things could be silent but I
would assume a controller will likely fetch some status information.
(When you kid returns home, you likely ask how it is doing. ;-)

/js

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 21 Mar 2017 09:05:29 -0400

> On Mar 21, 2017, at 7:55 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> To me, it feels a bit strange to make RFC 7594 normative

I agree, there is nothing specified in RFC 7594 that needs to be implemented in order for the YANG model to be implementable.

Alissa

> but if there

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 21 Mar 2017 16:50:31 +0200

On Tue, Mar 21, 2017 at 3:05 PM, Alissa Cooper <[email-masked]> wrote:

>
> > On Mar 21, 2017, at 7:55 AM, Juergen Schoenwaelder <
> [email-masked]> wrote:
> >
> >> thanks for you replies. I went back an had another look at the
> framework document which answered some of my questions. I guess the minimum
> you can do is to make the reference to RFC7594 normative (as well as the
> reference to I-D.ietf-lmap-information-model as Benoit mentioned in this
> comment). I guess without trying to implement it, I will not be able to
> figure out if there is anything missing or if I’m missing something and as
> such I will clear my discuss now.
> >
> I agree, there is nothing specified in RFC 7594 that needs to be
> implemented in order for the YANG model to be implementable.
>
> Alissa
>
> > but if there

My 2 agorot as WG co-chair: Making 7594 normative looks to me different
that our usual practice for normative references, however, if this is the
last obstacle between this document and its approval I would hold my breath
as well.

Regards,

Dan

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 21 Mar 2017 16:04:32 +0100

I cleared my discuss, so there is no obstacle here that blocks publication. I 
strongly agree with Benoit that this draft needs at least a normative 
reference to I-D.ietf-lmap-information-model. And similar as the reference to 
the information model, I had the feeling that you also need to read at least 
parts of RFC7594 to understand the terms, processes and goals in this 
document correctly. It's on you to decide. This is only my recommendation as 
a potential consumer. Not sure what your usual practice is but for normative 
reference the only question that relevant is: does the reader need to read 
the referenced document to fully understand the content of this document?

Mirja

On 21.03.2017 15:50, Dan Romascanu wrote:
>
>
> On Tue, Mar 21, 2017 at 3:05 PM, Alissa Cooper <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     > On Mar 21, 2017, at 7:55 AM, Juergen Schoenwaelder <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     >> thanks for you replies. I went back an had another look at the framework document which answered some of my questions. I guess the minimum you can do is to make the reference to RFC7594 normative (as well as the reference to I-D.ietf-lmap-information-model as Benoit mentioned in this comment). I guess without trying to
>     implement it, I will not be able to figure out if there is anything
>     missing or if I’m missing something and as such I will clear my discuss now.
>     >
> My 2 agorot as WG co-chair: Making 7594 normative looks to me different that
> our usual practice for normative references, however, if this is the last
> obstacle between this document and its approval I would hold my breath as well.
>
> Regards,
>
> Dan
>
>
>

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 21 Mar 2017 17:15:58 +0200

Thanks for clearing, Mirja.

I actually agree with your statement about normative references, but I
believe that the relationship of this document with the informational
framework RFC is different than the relationship with the information model
mentioned in Benoit's comment.

Regards,

Dan

On Tue, Mar 21, 2017 at 5:04 PM, Mirja Kühlewind <[email-masked]>
wrote:

> I cleared my discuss, so there is no obstacle here that blocks
> publication. I strongly agree with Benoit that this draft needs at least a
> normative reference to I-D.ietf-lmap-information-model. And similar as
> the reference to the information model, I had the feeling that you also
> need to read at least parts of RFC7594 to understand the terms, processes
> and goals in this document correctly. It's on you to decide. This is only
> my recommendation as a potential consumer. Not sure what your usual
> practice is but for normative reference the only question that relevant is:
> does the reader need to read the referenced document to fully understand
> the content of this document?
>
> Mirja
>
>
>> [email-masked]
>> comment). I guess without trying to
>> that