Subject: Re: [lmap] Learning MA Capabilities

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Apr 2016 14:48:38 +0200

On Thu, Mar 31, 2016 at 08:53:17PM -0400, Ron Stana wrote:
> LMAP Team,
> 
> We want the MA to provide information to the Controller that will be used
> to characterize/limit the Measurement Tasks that are later executed.
> 
> Examples include:
> 
>    - licenses for optional features
>    - max test bandwidth
>    - total number of simultaneous tests and data streams (based on VM
>    resources for virtual devices)
> 
> This appears to be information that LMAP suggests can be provided as part
> of getting the capabilities from the MA.  I have two questions based on
> version 9 of the LMAP Information Model.

This is not modelled in the information model.
 
> 1) Which API should be used to pass this information from the MA to the
> Controller?
> 
>    - ietf-lmap-control:lmap-state seems logical however there doesn't
>    appear to be a place for this type of information in it
>    - One possibility is to define a 'capability task' whose
>    ietf-lmap-control:lmap/tasks/task/option contains the data.  The controller
>    could then GET the ietf-lmap-control:lmap object to the values.  However, I
>    am not sure if tasks were envisioned to return data in this manner.

The results go to the collector and not to the controller.

> 2) While looking into how to solve this issue we found
> https://tools.ietf.org/html/rfc7223.  Has any consideration been given to
> adding the 'interfaces' or 'interfaces-state' objects defined in that
> document to ietf-lmap-control/lmap-state?  This would partially address the
> issue above but more importantly being able to get general RX and TX
> statistics on the test interface would be useful for general MA
> troubleshooting.

The YANG data model says:

   o  Capability and Status Information: Some of the status information
      is modeled in the /lmap-state/agent subtree and the /lmap-state/
      schedules subtree.  Information about network interfaces can be
      obtained from the interfaces YANG data model [RFC7223].

In other words, to expose interface details and statistics one should
implement RFC7223.

/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: Ron Stana <[email-masked]>
Date: Tue, 5 Apr 2016 09:47:24 -0400

Juergen,

For #1, learning the MA's capabilities, please confirm this is the expected
use case:

1) MA is provisioned with predefined channel information for Controller
2) MA registers with Controller
3) Controller wants to dynamically learn the MA's capabilities so it reads
either ietf-lmap-control:lmap or ietf-lmap-control:lmap-state to learn the
device type and a list of tasks
4) Based on predefined information (i.e. hard coded), the controller uses
the device type to know which task or tasks will tell it the capabilities.
5) Controller automatically submits the necessary schedules for the
capability task(s) and result task (task that defines collector channel).
It uses predefined channel information for the collector and presumably an
immediate event for all the schedules. Most likely the capability tasks
don't take any inputs.
6) Controller then requests data from Collector until it arrives from these
tasks.

I just want to confirm this is correct, since I expected the capability
learning to just be a simple data exchange between the Controller and MA.

For #2,

To add support for RFC7223, please confirm the expectation is that a vendor
would extend the ietf-lmap-control:lmap-state model so the extra
information could be included.  I didn't think the LMAP data models were
expected to be extended, but if this is acceptable then it seems like the
capability information could also be added to ietf-lmap-control:lmap-state,
which would simplify the capability learning process by limiting it to just
a read of ietf-lmap-control:lmap-state.

Ron

On Tue, Apr 5, 2016 at 8:48 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Apr 2016 15:53:27 +0200

> learning to just be a simple data exchange between the Controller and MA.

I do not understand what steps 4), 5), 6) would do. I guess I am not
sure what you consider 'MA capabilities' that are not covered in the
information or data model.
 
> a read of ietf-lmap-control:lmap-state.

No, the expectation is that a controller can pick relevant information
out network interfaces from the data model described in RFC7223. There
is no point in replicating this information.

/js

---

From: Ron Stana <[email-masked]>
Date: Tue, 5 Apr 2016 23:36:47 -0400

Juergen,

Steps 4,5 & 6 are performed to learn the dynamic capabilities of the MA.
For example, when the MA is a software-only implementation, the
capabilities will vary depending on what hardware it is installed on.
Depending on the number of CPUs, type of NIC, etc the number of tests, test
options and test parameter ranges may vary.  This is the type of
information that is not expected to change after the MA has been installed
but it still needs to be read at least once by the Controller.

For support of RFC7223, are you suggesting the MA should implement an API
outside of the LMAP models to return that information?

Ron

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Apr 2016 11:14:32 +0200

> outside of the LMAP models to return that information?

For a YANG-based solution, RFC 7223 (and any other relevant YANG data
model) leads to a well-defined way to obtain this information. There
is no point in duplicating this work.

/js

---

From: Ron Stana <[email-masked]>
Date: Sun, 24 Apr 2016 13:36:23 -0400

Juergen,

Can you explain how we can implement RFC-7233 without modifying the LMAP
YANG model?  I don't see fields in the LMAP YANG model for returning the
specific fields defined in RFC-7233 and I don't see a generic set of fields
in the LMAP YANG model that could be used to return it either.

I think the LMAP ietf-lmap-control model should be updated to include a
generic set of read-only attributes within the agent object.  This generic
set of read-only attributes could be defined the same way was the option
object that exists within schedule/action and task objects.  This means
each read-only attribute would consist of an id and value and the value
could contain structured data.  This way, the device specific capabilities
I am asking about such as software licenses, number of simultaneous tests,
etc can be learned by the controller and the RFC-7233 data can be returned:

        +--rw interfaces
        |  +--rw interface* [name]
        |     +--rw name                        string
        |     +--rw description?                string
        |     +--rw type                        identityref
        |     +--rw enabled?                    boolean
        |     +--rw link-up-down-trap-enable?   enumeration
        |  +--ro last-started    yang:date-and-time
        +--ro interfaces-state
           +--ro interface* [name]
              +--ro name               string
              +--ro type               identityref
              +--ro admin-status       enumeration
              +--ro oper-status        enumeration
              +--ro last-change?       yang:date-and-time
              +--ro if-index           int32
              +--ro phys-address?      yang:phys-address
              +--ro higher-layer-if*   interface-state-ref
              +--ro lower-layer-if*    interface-state-ref
              +--ro speed?             yang:gauge64
              +--ro statistics
              +--ro discontinuity-time    yang:date-and-time
              +--ro in-octets?            yang:counter64
              +--ro in-unicast-pkts?      yang:counter64
              +--ro in-broadcast-pkts?    yang:counter64
              +--ro in-multicast-pkts?    yang:counter64
              +--ro in-discards?          yang:counter32
              +--ro in-errors?            yang:counter32
              +--ro in-unknown-protos?    yang:counter32
              +--ro out-octets?           yang:counter64
              +--ro out-unicast-pkts?     yang:counter64
              +--ro out-broadcast-pkts?   yang:counter64
              +--ro out-multicast-pkts?   yang:counter64
              +--ro out-discards?         yang:counter32
              +--ro out-errors?           yang:counter32

Ron

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Apr 2016 10:42:58 +0200

> in the LMAP YANG model that could be used to return it either.

He? You can implement RFC 7233 standalone. Why would there be special
fields required in LMAP?

>               +--ro out-errors?           yang:counter32

This does not make sense to me. Why solve a problem that has already
been solved? There is really nothing that says a controller is only
allowed to look at LMAP objects. It is a feature to not repeat what
has already been specified elsewhere.

/js

---

From: Ron Stana <[email-masked]>
Date: Mon, 25 Apr 2016 08:57:28 -0400

Juergen,

I thought the goal of LMAP was to provide a common API for managing test
devices; providing a specific implementation for common operations and a
pass-thru mechanism for device-specific data.  Since it does that for
tests, I thought it was trying to do that for capabilities and status as
well.  From your response it seems like it is expecting proprietary APIs to
be used for obtaining status and capability information not defined by
LMAP.  Please confirm and if this is correct I would propose that this be
stated in the LMAP documentation. Note that I am not arguing for one way or
the other, I am just trying to understand what is expected.

Ron

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Apr 2016 15:14:08 +0200

> the other, I am just trying to understand what is expected.

There is no need to use proprietary APIs.

You can use NETCONF or RESTCONF to access the ietf-interfaces YANG
data model in the same way you use NETCONF or RESTCONF to access the
ietf-lmap-control YANG data model.

/js

---

From: Ron Stana <[email-masked]>
Date: Mon, 25 Apr 2016 13:08:48 -0400

Juergen,

I was using the term 'proprietary' incorrectly.  I was intending it to mean
'device-specific' but it really means 'vendor-specific'.

I can see now that having additional standards-based implementations is in
agreement with LMAP and so implementing RFC-7223 outside of LMAP is
acceptable for extending the interface state information.  While this
results in device-specific implementations, they are not vendor-specific.

Concerning how an LMAP client learns the vendor specific capabilities of an
MA, are you in agreement that this would require a vendor-specific API?
Since test configurations consist of vendor-specific information and LMAP
addresses this, I thought LMAP might also provide an approach for
vendor-specific capabilities.  I can understand if this is outside the
scope of LMAP and so left for vendors to provide.

Ron

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Apr 2016 19:21:38 +0200

> MA, are you in agreement that this would require a vendor-specific API?

No.

> scope of LMAP and so left for vendors to provide.

RFC 7223 is as interoperable as the LMAP YANG data model. There is a
standard mechanism to discover the data models supported, the details
depend on the protocol. I do not understand why you see a requirement
for vendor-specific APIs from the use of RFC 7223.

/js

---

From: Ron Stana <[email-masked]>
Date: Mon, 25 Apr 2016 14:56:05 -0400

Juergen,

RFC-7223 just offers extra information about the network interfaces.  My
original question was two-fold: how does an MA let a client know about
vendor-specific capabilities during the Controller & MA
registration/capabilities process and would the approach taken for this be
similar for extending the status to include something like RFC-7223 during
the Controller & MA status retrieval process.  I now understand if a device
wants to support RFC-7223 it just implements it outside of LMAP - thank you
for clarifying this.

The registration and capabilities exchange is a separate part of the LMAP
architecture and that is the part I am still asking about.  There will be
vendor-specific capabilities that clients of the MAs will need to obtain so
they understand the limitations of a given device and adjust test
configurations accordingly.  For example, when dealing with test devices
that are installed as virtual machines on various hardware platforms, the
number of simultaneous tests and data streams generated supported can vary
based on the amount of memory, hard drive space and NIC.  These same
capabilities could also be limited by licenses/software options.  I am
trying to determine if this type of information is expected to be obtained
by the controller during the capabilities exchange or if it is done outside
of LMAP.

Ron

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Apr 2016 21:24:34 +0200

> by the controller during the capabilities exchange or if it is done outside

The LMAP capability definitions cover hardware and firmware
description and the version of the measurement agent. This is about
it. If a vendor wants to provide additional information, the vendor
can extend the models. Note that there is already some resistance to
report or control the storage managed by the LMAP agent itself.

The good news is that there may be eventually an equivalent of the
HOST-RESOURCES-MIB in the YANG world and that would give you at least
some information about storage and processing resources - but from
that you would still not know how many tests you can run concurrently
without risking the tests to impact each other. I guess this is all
out of scope for now, we are better off with trying to finish LMAP
version 1, getting implementation and deployment experience, and then
we hopefully better understand what needs to be changed or added.

/js