Subject: [lmap] draft-burbridge-lmap-information-model

From: "Bajpai, Vaibhav" <[email-masked]>
Date: Wed, 10 Jul 2013 12:09:43 +0000

Hello,

I read the draft [1] and made some notes. Thought to share them along:

[1] http://tools.ietf.org/html/draft-burbridge-lmap-information-model-00

- version of measurement test:

  1.  Measurement Task Configuration: Object

          1.  Task Name
          2.  Registry Entry: URN
          3.  Options: Set (optional)
          4.  Measurement Cycle ID: String (optional)

It would be useful to convey the version of measurement test no?

A version bump will usually come due to a bugfix in a specific measurement
test implementation. The version information will help later segregate
measurement results coming out from different measurement test
implementations. hmm?

- measurement time in result report

   5.  Measurement Task: Set

          1.  Measurement Task Configuration: Object
          2.  Result Headers: List
              1.  Column Name: String
          3.  Result Data: List
              1.  Result Row: Object
                  1.  Measurement Time: datetime
                  2.  Cross-traffic: Integer (optional)
                  3.  Result Columns: List
                      1.  Column Data

Would it be useful to have explicit START (datetime) and END (datetime) in
replacement for the Measurement Time (datetime)? I mean the START and END
times when the measurement was performed.

- pre-configured information:

 Detail of the information model elements:

  1.  MA MAC: MAC Address
  2.  Controller: FQDN
  3.  MA Certificate: Certificate
  4.  Controller Communication Timing: Timing

maybe we should add these too, no? (it is discussed in the previous paragraph,
just seems to be missing from the list of items)

  5.  MA Private Key
  6.  CA certificate

- configuration information (retrieved from controller):

  1.  Measurement Agent ID: String
  2.  Measurement Group ID (optional): String
  3.  Report MA ID flag (optional): Boolean

If I understand correctly, this is additional information sent, when the MA
registers with the controller for the first time. In the LMAP protocol draft
[draft-bagnulo-lmap-http-00], however, we assume that the MA UUID is baked in
as part of the pre-configured information in the MA.

[draft-bagnulo-lmap-http-00] -

  In particular each MA has a version 4 UUID, which is
  randomly or pseudo randomly generated.  We assume that the UUID is
  preconfigured in the MA before deployment.

This could also be because in the LMAP protocol draft
[draft-bagnulo-lmap-http-00], we only have pre-configured information, and
the controller is only contacted to receive measurement instructions
(measurements, schedule, reporting channels).  Probably, we should discuss and
synchronize this no?

- measurement protocol

  and several measurement protocols between the MAs used to actually perform
  the measurements.

I searched the terminology document [draft-eardley-lmap-terminology-01], but
could not find a description of measurment protocol.

- measurement suppression instruction is defined in the information model, but
  is not discussed in the terminology [draft-eardley-lmap-terminology-01] and
  LMAP protocol drafts [draft-bagnulo-lmap-http-00].

Best, Vaibhav

-----------------------------------------------------
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: <[email-masked]>
Date: Wed, 10 Jul 2013 13:35:40 +0100

Hi Vaibhav, thanks for the very useful comments/discussion.

See inline for my answers....

Trevor.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Bajpai, Vaibhav
>Sent: 10 July 2013 13:10
>To: [email-masked]
>Cc: Bajpai, Vaibhav; <[email-masked]>
>Subject: [lmap] draft-burbridge-lmap-information-model
>
>Hello,
>

Yes I agree. I considered and then removed some 'metadata' on the information objects: namely author, creation date, name (where not required by the MA as a reference, description and version number since I didn't want to clutter the first version too much. However I think I was over-zealous since I agree that the Measurement Configuration Version is something that should be reported by the MA.

>replacement for the Measurement Time (datetime)? I mean the START and
>END times when the measurement was performed.

I think the tests for which this is relevant can report a duration data column or even an end time if they want/prefer. Not against the idea, I just don't know it is required in the IM as it would be optional (since many tests wouldn't want to record or report this). I can see the point in having it in the standard IM though if you do want to isolate any measurement results that were conducted entirely within a period - just not sure how useful this is.

>maybe we should add these too, no? (it is discussed in the previous
>paragraph, just seems to be missing from the list of items)
>
>  5.  MA Private Key
>  6.  CA certificate

I originally had the certificate on the Controller and Collector in the IM. However, since these will be provided as required and fetched/validated outside the LMAP framework I removed them. Not against putting them back in, but not sure if strictly necessary.

>[draft-bagnulo-lmap-http-00], however, we assume that the MA UUID is
>baked in as part of the pre-configured information in the MA.
>
>This could also be because in the LMAP protocol draft [draft-bagnulo-lmap-
>http-00], we only have pre-configured information, and the controller is only
>contacted to receive measurement instructions (measurements, schedule,
>reporting channels).  Probably, we should discuss and synchronize this no?

This is an important discussion I think. Either the MA is given an ID when it registers, or it is pre-configured with and ID. I tended to prefer the first option since it allows IDs to be allocated depending on the registration context. It also doesn't waste ID space on MAs that may never be switched on. It also enables multiple vendor devices pre-configured by those vendors to receive guaranteed unique MAs from the Controller.

I'm not yet convinced the ID is required in order to contact the Controller, so the bottom line is that it can be allocated at registration.

>I searched the terminology document [draft-eardley-lmap-terminology-01],
>but could not find a description of measurment protocol.
>
>
>
>
>