Subject: [lmap] review: draft-bagnulo-lmap-http-01

From: "Bajpai, Vaibhav" <[email-masked]>
Date: Mon, 2 Jun 2014 15:32:14 +0000

Hello,

I read the LMAP HTTP protocol document [1] and made some notes.
[1] http://tools.ietf.org/html/draft-bagnulo-lmap-http-01

Here is my proposal on how to take this work forward:

  Overview
  ~~~~~~~~

   Once that the MA is deployed it will perform the following operations:

   o  After the MA is deployed, it will obtain Instructions from one of
      the pre-configured Controllers.  These Instructions include
      information about the set of measurements to be performed, a
      schedule for the execution of the measurements as well as a set of
      report channels.  This information is downloaded by the MA from
      the Controller.  The MA will periodically check whether there are
      new Instructions available from the Controller.  This document
      specifies how the MA uses the HTTP protocol to retrieve
      information from the Controller.

According to the information model [draft-ietf-lmap-information-model-00].
Before ^, MA also needs to:

a) Contact the initial controller to retrieve configuration information.

I personally think it also must send capabilities before asking for
instructions. The controller will bake instructions depending on the received
MA capabilities:

b) Send MA capabilities over the MA-to-controller channel.

I can provide a writeup for a) and b) if need be.

   o  The MA will execute measurements either by passively listening to
      traffic or by actively sending and receiving measurement packets.
      How this is done is out of the scope of this document.

   o  After one or more measurements have been performed, the MA reports
      the results to the Collector.  The timing of these uploads is
      specified in the measurement Instruction i.e. each measurement
      specified in a measurement Instruction contains a report
      information, defining when the MA should report the results back
      to the Collector.  This document specifies how the MA uses the
      HTTP protocol to upload the measurement results to the Collector.

   o  In addition, the MA will periodically report back to the
      Controller information about its capabilities (like the number of
      interfaces it has, the corresponding IP addresses, the set of
      measurement methods it supports, etc) and also logging information
      (whether some of the requested measurement tasks failed and
      related information).

According to the information model [draft-ietf-lmap-information-model-00]:

c) The MA also executes task objects that perform logging and status
reporting.  These task objects instead send the results over the
MA-to-controller channel.  Perhaps, we should merge ^ bullets to state that
the schedule is agnostic to what kind of task is being run.

  Information Model
  ~~~~~~~~~~~~~~~~~

  The control information (or Instruction) has the following five elements:

  o  The Agent Information element.  This contains pointers (URLs) to
    the other 4 elements which contain the actual control information.
    This serves as a level of indirection allowing the MA to have a
    root element from which retrieve all the other elements.

a) This ^ is the instruction object as per the information model
[draft-ietf-lmap-information-model-00]. Shall we replace "Agent Information"
with "Instruction Information"?

  o  The Set of Measurement Task Configurations: This element defines
    the measurements/test that the MA will perform without defining
    the schedule when they will be performed.

  o  The Set of Report Channels: This element defines the set of
    collectors as well as the reporting schedules for the reports.

b) The MA also performs logging and status reporting that goes over the
MA-to-controller channel. Perhaps we should replace "report channels" with
"channels" to make this generic that covers all aspects. I also raised this
issue in the information model document [draft-ietf-lmap-information-model-00].

  o  The Set of Measurement Schedules for Repeated Tasks: defines the
    schedules for the repeated measurements, by referencing the
    measurement tasks defined in the second element.
  o  The Set of Measurement Schedules for Isolated Tasks: defines the
    schedules for isolated measurements, again by referencing the
    measurement tasks defined in the second element.

c) The information model [draft-ietf-lmap-information-model-00] does not
distinguish between schedules of isolated and repeated tasks. Perhaps we
should merge these 2 bulleted items and call them measurement schedules?

d) We are missing discussion on supression object.

  Summary of Report information model here.

  Summary of Status information model here.

e) This is referred as "capability and status information" in the information
model [draft-ietf-lmap-information-model-00].

  Summary of Logging information model here.

f) This is referred as "MA-to-controller" information in the information model
[draft-ietf-lmap-information-model-00]. I personally think we should rename
the information model section name to logging.

  Summary of Configuration information model here.

g) This should be discussed before the instruction information model.
h) We are also missing discussion on pre-configuration information.

  Example
  ~~~~~~~

  Once the MA is deployed, it uses the POST method to retrieve the Agent
  Information element of the Instruction from the controller as follows

  POST /.well-known/lmap/ma-info/ HTTP/1.1
  Host: controller.example.com
  Content-Type: application/lmap-maid+json
  Accept: application/lmap-config+json
  {
    "ma-id" : "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  }

a) Within the information model [draft-ietf-lmap-information-model-00], this
is a request to fetch the instruction object. I think we should replace
references to "agent information" with "instruction object". Additionally, the
POST request must be made to the instruction channel target. I think the
.well-known mechanism is only used for registration with the initial
controller.

As per the information model [draft-ietf-lmap-information-model-00], before
retrieving the instruction object as ^, the MA must do these things:

b1) Register and retrieve the configuration information (MA ID, instruction
channel, and MA-to-controller channel) by sending a POST request with its
device ID to the intial controller embedded in the pre-configured instruction
channel. We are missing this example.

b2) This registration mechanism must also be idempotent.

I personally also think, that the MA should send its capabilities before
retrieving the instruction object:

c) Send MA capabilities over the configured MA-to-controller channel to the
controller. The controller will use this information to prepare an instruction
object to be sent to the MA on further request. We are missing this example.

  For this particular example, the Agent information returned looks like this:

  {
     "ma-id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
     "version": "1.0",
     "measurement-set": "http://controller.example.org
               /measurements/",
     "report-channel-set": "http://controller.example.org
               /channels/",
     "repeated-schedule-set": "http://controller.example.org
               /schedules/"
     "status-set": "http://controller.example.org
                       /status/"
     "logging-set": "http://controller.example.org
                           /logging/"
  }

According to the information model [draft-ietf-lmap-information-model-00]:

a) "measurement-set" should be "ma-tasks"

b) "report-channel-set" should be "ma-report-channels" (I personally think
this should be ma-channels)

c) "repeated-schedule-set" should be "ma-schedules"

d) "status-set" and "logging-set" are part of a) and should be removed. The
MA-to-controller channel used to send these objects is sent during
configuration.

e) We are missing a pointer to "ma-suppression"

  The first thing that the MA does is to send its status information to
  the Controller. this contains information about the MA capabilities
  and local configuration, such as interfaces' information and
  supported measurement task.  For this particular example, the MA
  would execute the following method:

a) I think we should decouple status and capability reporting. Capabilities
are fairly static while status objects need to be periodically reported. I
also raised this issue in the information model review
[draft-ietf-lmap-information-model-00].

  POST /.well-known/lmap/ma-info/ HTTP/1.1
  Host: controller.example.com
  Content-Type: application/lmap-maid+json
  Accept: application/lmap-config+json
  {
   "ma-id" : "f47ac10b-58cc-4372-a567-0e02b2c3d479",
       "ma-interfaces: [
             {"if-name" : eth0
              "if-type" : ethernetCsmacd
              "ip-adddress" :{
                     "protocol": v4
                     "address": 10.1.1.1
                     }
              }]
        "supported-measurements":[
              {"metric": UDP_Latency}]
  }

b) The ^ example is only sending capabilities. We need an example on how to
send status objects.

c) Shouldn't we use a target specified in the MA-to-controller channel to send
capability and status information? The ^ example is sending a POST to a
generic .well-known location.

d) "supported-measurements" according to the information model
[draft-ietf-lmap-information-model-00] is "ma-tasks"

   The MA will next retrieve the set of Instructions from the
   Controller.  The POST for the Instructions will result in the
   following information:

/s/Instructions/Tasks

  Transport protocol
  ~~~~~~~~~~~~~~~~~~

  6.1.  Pre-configured information
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     o  The UUID for the MA.  This should be pre-configured so that the
        Controller is aware of the MA and can feed configuration
        information and measurement Instructions to it.

a) The information model [draft-ietf-lmap-information-model-00] keeps this
open. The MA UUID can either be pre-configured or provided by the initial
controller during the configuration setup when MA registers a device ID.
Trevor and I discussed this previously, and I think Trevor was hinting towards
preferring the latter approach. I also prefer retrieving UUID from the
controller.

  6.2.  Control Protocol
  ~~~~~~~~~~~~~~~~~~~~~~

  The MA uses the Control protocol to retrieve all the resources described
  above, namely, the Agent information, the Set of Measurement Task
  Configurations, the Set of Report Channels, the Set of Measurement Schedules
  for Repeated Tasks and the Set of Measurement Schedules for Isolated Tasks.

a) The information model [draft-ietf-lmap-information-model-00] does not make
a separation between schedules for repeated tasks and isolated tasks. It just
proposes to use a timing-obj that eventually decides the behavior of the
schedule. I think we should merge ^ definitions.

  6.2.1.1.  Using the GET method
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  The frequency for the periodical retrieval is contained in the Agent
  Information (???).

  Agent Information retrieval: In order to retrieve the Agent
  information the MA uses the HTTP GET method follows:
    GET /.well-known/lmap/ma-info/ < ma-iid> HTTP/1.1
    Host: FQDN or IP of the Controller
    Accept: application/json (as per [RFC4627])
  The Agent Information should contain the Configuration Retrieval
  Schedule (i.e. how often the MA should retrieve configuration
  information) and also the Measurement Instruction Retrieval Schedule
  (i.e. how often the MA should retrieve the Measurement Instruction
  from the Controller).  COMMENT: this is missing from the Data Model

a) The term "Agent Information" is not defined in the information model
[draft-ietf-lmap-information-model-00].

b) According to the information model [draft-ietf-lmap-information-model-00],
the schedules however are sent as part of the instruction object retrieval.

c) I think RFC 4627 has been recently obsoleted by RFC 7159.

  6.2.2.  Handling communication failures
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  o  The MA will use a timeout for the communication of TIMEOUT
    seconds.  The value of TIMEOUT MUST be configurable via the
    aforementioned Configuration Information retrieval protocol.  The
    default value for the TIMEOUT is 3 seconds.  If after the timeout,
    the communication with the Controller has not been established,
    the MA will retry doing an exponential backoff and doing a round
    robin between the different Controllers it has available.

a) In the information model [draft-ietf-lmap-information-model-00], the
instruction channel allows only 1 controller target. The idea of doing a
round-robin between available controllers on ocassions of TIMEOUT may save the
MA at multiple occassions. Shall we use this concept in the information model
by changing the target to an array?

  6.3.1.  Handling communication failures
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  If the MA is uploading the report to several Collectors and it
  manages to establish the communication before TIMEOUT seconds with at
  least one of them, but not with one or more of the other Collectors,
  then the MA gives up after TIMEOUT seconds and it MAY issue an alarm.
  The definition of how to do that operation is out of the scope of
  this document.

a) What should the MA do when it has results to upload, but cannot contact any
collector? The schedule is running and constantly increasing the size of the
results as the time goes by. When should it decide to drop all collected
results to make sure it doesn't go out of space?

  Editorial Changes
  ~~~~~~~~~~~~~~~~~

  The reader is referred to the terminology draft for further details.

a) The terminology draft is merged with the framework draft, no?

b) [I-D.ietf-lmap-framework] is obsolete
   [I-D.burbridge-lmap-information-model] is obsolete.
   [I-D.bagnulo-ippm-new-registry-independent] is obsolete.

  o  Measurement protocols: These are the protocols used between the MA
    and the Measurement Peer in active measurements.  These are the
    actual packets being used for the measurement operations.

c) The "measurement protocol" term is not defined in the framework document.

-----------------------------------------------------
Vaibhav Bajpai

Research I, Room 86
Computer Networks and Distributed Systems  (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 4 Jun 2014 10:56:26 +0000

Thank you for your comments, Vaibhav. 

I notice that this I-D is expired. Maybe the authors plan for an update incorporating the comments. In any case, it would be good for the I-D to be re-submitted, as the WG must do progress soon on the LMAP protocols proposal (as well as data models) and it's a very good time for such individual submissions to be made in order to be considered for discussion before IETF 90. 

Regards,

Dan

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of Bajpai, Vaibhav
> Sent: Monday, June 02, 2014 6:32 PM
> To: <[email-masked]>
> Cc: Bajpai, Vaibhav
> Subject: [lmap] review: draft-bagnulo-lmap-http-01
> 
> Hello,
> 
> I personally think it also must send capabilities before asking for instructions.
> The controller will bake instructions depending on the received MA
> capabilities:
> 
> reporting.  These task objects instead send the results over the MA-to-
> controller channel.  Perhaps, we should merge ^ bullets to state that the
> schedule is agnostic to what kind of task is being run.
> 
> 
>   Information Model
>   ~~~~~~~~~~~~~~~~~
> 
> a) This ^ is the instruction object as per the information model [draft-ietf-
> lmap-information-model-00]. Shall we replace "Agent Information"
> b) The MA also performs logging and status reporting that goes over the MA-
> to-controller channel. Perhaps we should replace "report channels" with
> "channels" to make this generic that covers all aspects. I also raised this issue
> in the information model document [draft-ietf-lmap-information-model-00].
> 
> As per the information model [draft-ietf-lmap-information-model-00],
> before retrieving the instruction object as ^, the MA must do these things:
> 
> a) I think we should decouple status and capability reporting. Capabilities are
> fairly static while status objects need to be periodically reported. I also raised
> this issue in the information model review [draft-ietf-lmap-information-
> model-00].
> 
> c) Shouldn't we use a target specified in the MA-to-controller channel to
> send capability and status information? The ^ example is sending a POST to a
> d) "supported-measurements" according to the information model [draft-
> ietf-lmap-information-model-00] is "ma-tasks"
> 
> a) The information model [draft-ietf-lmap-information-model-00] does not
> make a separation between schedules for repeated tasks and isolated tasks.
> It just proposes to use a timing-obj that eventually decides the behavior of
> the schedule. I think we should merge ^ definitions.
> 
> 
> instruction channel allows only 1 controller target. The idea of doing a round-
> robin between available controllers on ocassions of TIMEOUT may save the
> MA at multiple occassions. Shall we use this concept in the information
> model by changing the target to an array?
> 
> 
> a) What should the MA do when it has results to upload, but cannot contact
> any collector? The schedule is running and constantly increasing the size of
> the results as the time goes by. When should it decide to drop all collected
> Computer Networks and Distributed Systems  (CNDS) Lab School of
> Engineering and Sciences Jacobs University Bremen, Germany
> 
> www.vaibhavbajpai.com