Subject: [lmap] Comments on draft-schulzrinne-lmap-requirements-00

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 10 Oct 2012 18:05:16 +0200

Hi again,

I also have some more technical comments relating directly to the draft (maybe 
restarting the technical discussion).

1. I agree with previous comments that the role of the network parameter 
server is not clear. I would expect rather than having an own entity that the 
client system would get the needed parameters from the controller. The 
controller as well as someone how wants to evaluate the data might need these 
parameters as well. But it not clear how to retrieve those parameters. Some 
of them might be enter manually, some could be discovered over SNMP. I don't 
see that there have to be one single entity administrating all parameters. 
But I'd say all these questions are out of scope.

2. I also agree with previous comments that infact the client and the server 
might implement the same functionality. Those are simply measurement 
endpoints. A measurement can be started by the client or the server. During 
the measurement both endpoints might collect data and either exchange these 
data between each other or send them directly to a data collector. The case 
where measurement results need to be exchanged between the endpoints (client 
and server) is not address in the draft so far.

3. There might also be some kind of hierarchy between data collectors. If I 
use more than one data collector for load balancing reasons. I guess those 
single collectors could do some kind of preprocessing but then I still need 
one entity to correlate all data to get a view on my whole network. Thus 
maybe a protocol to query the data should be regarded as well. Btw. there can 
already be some kind of preprocessing at the measurements endpoint 
(client/server) as well. 

-> All over we might only need two protocols. One to request or initiate 
measurements and one to request or exchange measurement data. 
The first one can be used between the controller and measurement endpoint, as 
well as between measurement endpoints and between controllers in a 
hierarchical structure.
The second one can be used between the measurement point and the data 
collector (where the measurement might also be able to store and evaluate the 
data) and as well between measurement points and data collectors and also 
between the controller and the data collector/measurement endpoints (as the 
controller might need previous results to configure new measurement runs).

Both protocols will also need some kind of capacity negotiation as well as 
some kind of authentication and integrity check.

What do you think?

Mirja