Re: [lmap] my comments on draft-akhter-lmap-framework-00

[Paul Aitken <[e-mail]>]

Dan, Thanks for your feedback. Please find some replies inline:


On 24/07/13 12:28, Romascanu, Dan (Dan) wrote:
> Please find below a set of comments after my first reading of draft-akhter-lmap-framework-00. These are made from the perspective of contributor, and take into account the fact that this is a 00 individual submission, so idnits was not run, spelling and references were not checked, etc.
>
> 1. The name of the I-D speaks about 'Inventory' which is a little bit confusing or mis-reading. Actually the authors rather seem to have described some applications and protocols that fit into the LMAP architecture, so it's rather an incomplete 'taxonomy'. See more when talking about the (lack of) requirements.

We started by making an inventory of the existing/missing IETF blocks, 
which evolved towards a framework.


> 2. The previous contributions on LMAP framework included in draft-eardley-lmap-framework were completely ignored, some material is duplicated (in content, not in text), but the eardley I-D is not even included in the list of references. As the two I-Ds (and other relevant contributions) will need to be consolidated into one single WG I-D pretty soon I will refer in the following to some of the similarities and some of the differences.

Sorry for not including draft-eardley-lmap-framework. We were debating 
whether to include it or not; we're happy to add it, though we'll be 
working with the other authors to merge the drafts anyway.


> 3. The order of Sections 1.2 and 1.3 should be reversed.

OK.


> 4. Figure 1 is almost identical to Figure 1 in draft-eardley with two differences. The first is that the entity named Measurement Peer in draft-eardley is called here Remote Measurement Test Target and seems to have a much richer functionality and variants as illustrated in Sections 3.2 and Figure 2. The option of one measurement agent communicating with multiple Remote Measurement Agents needs to bear a warning concerning scalability.

Yes, we agree about scalability. We'll add some use cases.


> 5. The second significant difference in the two diagrams is the communication between the Controller and the Collector. Later in the draft this is described as optional and motivated by the need to optimize for Collector Test Configuration synchronization (so that each MA needs not report its configuration to controllers). This addition to the basic architecture needs to be carefully discussed by the WG.

Controller to Collector communication is optional; we see this as an 
optimisation for large-scale tests. it could be up to the controller 
based on the number of MAs involved.
If the majority of the tests are single MAs, then this optimization 
works against. However, if there are more than 2 or 3 MAs, the 
optimisation works. We can discuss.


> 6. One crisp limitation that is being introduced by draft-eardley is about each MA being configured only by one Controller (motivated among other by the need of simplifying authentication of Controllers with the MA). This limitation is not mentioned in this I-D, at least not explicitly. Is this an editorial miss, or the authors take a different stand on this issue?

Multiple controllers are generally only for the case of redundancy 
failover; usually an MA has a relationship with only one controller at 
any time.
However, since all controllers are part of the same administrative 
domain which is centrally controlled, each can be understood as a 
different controller instance.
So an MA with multiple controllers is simply communicating with multiple 
controller instances - so allowing multiple controllers should not be 
problematic, since they should not issue contradictory instructions.

Multiple distinct controllers under different administrative control 
aren't within charter.


> 7. Sections 3,4,5 are to some extent written with one set of protocols already in mind to answer LMAP architectural requirements (OWAMP and TWAMP for active monitoring, PSAMP for passive monitoring, IPFIX for reporting protocol, IPFIX mediators to solve the scalability issues). Although this may be a reasonable set of solutions, it seems a little bit too early and too detailed at this phase. Missing here are the basic requirements for the Control protocol, Report protocol, and associated data models. I would prefer to see this being written first.

We started by talking about firewalls, NAT etc. We can add the basic 
requirements; there's already an analysis of OWAMP and TWAMP. We'll 
separate this out so there's clear separation between the requirements 
of those protocols and the analysis of the individual protocols.


> 8. The Security Consideration section needs to include not only information about authentication, but also about the risks of modification of information (data integrity).

We'll note that it's insecure in this particular way. Note that the 
charter says that gaming is outside the scope.


Aamer + Paul.