Re: [lmap] Feedback on draft-eardley-lmap-terminology

["Romascanu, Dan (Dan)" <[e-mail]>]

I agree that the draft is in pretty good shape, and that much of the terminology content is ready to be incorporated into the framework draft.

But we have two framework I-Ds at this point in time! This is not a bad thing and individual contributions are welcome at this point. However, we have a tight schedule to consolidate the two in one WG framework draft.

One of the points where the framework is still confusing for me and the terminology I-D does not help is the controller.

Says the terminology I-D:

Controller: A function that provides a Measurement Agent with
   Instruction(s).  Colloquially, a Controller is a physical device that
   performs this function.

Do we really envision physical devices that perform this (only) function?

More unclarity. The single controller (for a given MA) key assumption is not mentioned by draft-akhter-lmap-framework. Why? The other framework draft draft-eardley-lmap-framework doest take into account the key assumtion, but then talks about the MA pulling configuration from the Controller in order to avoid firewall traversal problems. Does this eliminate a-priori the usage of NETCONF as a possible transport for the Control Protocol?

Regards,

Dan


From: [e-mail] [mailto:[e-mail]] On Behalf Of Benoit Claise
Sent: Monday, July 22, 2013 7:12 PM
To: [e-mail]
Subject: [lmap] Feedback on draft-eardley-lmap-terminology

Dear authors,

A couple of high level points.
One of the goal behind this email is to generate discussions, either on the list, or during the IETF meeting next week.

-

   The consensus is that the LMAP working group should assume that a

   Measurement Agent receives Instruction from only a single Controller

   at any point in time (however it may Report to more than one

   Collector).
Instead of consensus, I would use "a key assumption"
The charter says:
A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator).
-
Same remark for the term "consensus" in

   The job of a Bootstrap Protocol is to provide an automated way to

   associate a Measurement Agent to its Controller, including

   authentication credentials.  Similarly, there should be a way to pull

   the plug on rogue Measurement Agents.  The current consensus on the

   LMAP mailing list is that the working group should define the

   bootstrap process but not a protocol.
The charter mentions:
"The management protocol to bootstrap the MAs in measurement devices is out of scope of the LMAP charter."
-
I would like to draw your attention to claise-ippm-perf-metric-registry<http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry>, which will be presented in IPPM.

-
I'm not too clear if the Measurement Peer are dedicated test server, or real server (google.com, SIP server, youtube)
Do the Measurement Peer need the functionality of an IP SLA responder or a TWAMP controller?
This might be clarified in the use case draft.

-
This draft is good shape, but it's really a mix of terminology and framework concepts.
I'm glad that there is a single delivery in the charter for both:
"1. The LMAP Framework - provides common terminology, basic architecture elements, and justifies the simplifying constraints"


Regards, Benoit