Re: [lmap] AD review of draft-ietf-lmap-framework-10

[marcelo bagnulo braun <[e-mail]>]

Hi,

I have just submitted a new version of the draft with the proposed 
changes. Hopefully this clears the path for this draft moving forward.

The new version of the draft is:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lmap-framework-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-11

Regards, marcelo




El 22/02/15 a las 12:03, marcelo bagnulo escribió:
> Hi,
>
> Thanks for the review. I think we addressed all your points. We will 
> submit an updated version of the document now and if there are more 
> changes needed, we submit another one.
>
> El 17/02/15 a las 19:25, Benoit Claise escribió:
>> Dear all,
>>
>> First of all, very sorry for the delay in getting back to you.
>> Thank you for this new draft version. The document really improved 
>> between version 8 and 10.
>> Here is my feedback on version 10. Nothing major. I propose to start 
>> the IETF LC as soon a new version is posted
>>
>> - In http://tools.ietf.org/html/draft-ietf-lmap-use-cases-06, LMAP 
>> stands for Large-scale Measurement of Broadband Performance.
>> Here, in the abstract, it stands for large-scale measurement 
>> platforms. Please change it.
>>
>
> done
>
>
>> - Some repetitions in section 1
>>     It is expected
>>     that such a system could easily comprise 100,000 devices.
>>
>>        It is expected that a Measurement
>>        System could easily encompass a few hundred thousand or even
>>        millions of Measurement Agents.
>
> agree, rephrased as:
>
>       There is a desire to be able to coordinate the execution of 
> broadband
>       measurements and the collection of measurement results across a 
> large
>       scale set of Measurement Agents (MAs). These MAs could be 
> software based
>       agents on PCs, embedded agents in consumer devices (such as TVs or
>       gaming consoles), embedded in service provider controlled 
> devices such as set-top
>       boxes and home gateways, or simply dedicated probes.
>       MAs may also be embedded on a device that is part of an ISP's 
> network, such
>       as a DSLAM (Digital Subscriber Line Access Multiplexer), router, 
> Carrier
>       Grade NAT (Network Address Translator) or ISP Gateway.
>       It is expected that
>       a measurement system could easily encompass a few hundred 
> thousand or even
>       millions of such MAs. Such a scale
>       presents unique problems in coordination, execution and measurement
>       result collection.
>
>> - Section 2
>> OLD:
>>     Another possibility is for the
>>     MA may generate (or receive) traffic specially created for the
>>     purpose and measure some metric associated with its transfer.
>>
>> NEW:
>>     Another possibility is for the
>>     MA_to_generate (or receive) traffic specially created for the
>>     purpose and measure some metric associated with its transfer.
>
> ok
>
>>   - Section 2
>> OLD:
>>     Messages are transferred over a secure Channel.
>>
>> NEW:
>>     Both control and report messages are transferred over a secure 
>> Channel.
>
> ok
>
>
>> -
>> results repository or Results repository?
>> Please check all instances.
>>
>
> it is Results repository because Results is an LMAP defined term while 
> the repository it is not (it is out of the scope of the framework)
> The usage is consisten throughout the document.
>
>
>> - Figure 1
>> The Report goes over the Report Channel, not Control Channel
>>
> ok
>
>> - Figure 1
>> The traffic between "End user or Measurement Peer" represents the MA 
>> passive monitoring.
>> If you would add an arrow from the MA to End User or Measurement Peer 
>> on the right (to show that some MAs can generate active traffic), you 
>> would have a complete picture.
>> Something like this:
>>
>>     +-----------+                         +-----------+     ^
>>     |End user or|                         |End user or|     |
>>     |Measurement|                         |Measurement| Non-LMAP
>>     |  Peer     |                         |   Peer    |   Scope
>>     +-----------+                         +-----------+     v
>>         ^                                        ^ ^
>>          \ Observed +---------------+           / /         ^
>>           \.........|...............|........../ /          |
>>        Traffic Flow | Measurement ..|.........../           |
>>        +----------->|   Agent       |Measurement Traffic    |
>>        |            +---------------+                       |
>>
>> Note that I have reused your terminology: Measurement Traffic and 
>> Observed Traffic Flow
>>
> done
>
>> - Section 5.2.2
>> Instruction:                            ->
>>     [(Measurement Task configuration
>>         URI of Metric(
>>        [Input Parameter],
>>        (interface),
>>        (Cycle-ID))),
>>      (Report Channel),
>>      (Schedule),
>>      (Suppression information)]
>> Should we expect a 1:1 mapping between the parameters above and the 
>> list that follows?
>> For example, I see in the list
>>           * the Measurement Method role.  For some Measurement Methods,
>>           different parties play different roles; for example (figure A3
>>           in the Appendix) an iperf sender and receiver.  Each Metric 
>> and
>>           its associated Measurement Method will describe all 
>> measurement
>>           roles involved in the process.
>>
>>           * optionally, the measurement point designation
>>           [I-D.ietf-ippm-lmap-path 
>> <http://tools.ietf.org/html/draft-ietf-lmap-framework-10#ref-I-D.ietf-ippm-lmap-path>] 
>> of the MA and, if applicable, of the
>>           MP or other MA.  This can be useful for reporting.
>
> Right.
> I have include both the role and the measurment point in the figure.
>> - Section 5.2.2
>> I guess that most MAs will have one Report Channel, as the default 
>> option. Right?
>> OLD:
>>   o  configuration of the Report Channels, each of which needs:
>>
>> NEW:
>>   o  configuration of the Report Channel(s), each of which needs:
> ok
>
>> - Section 5.2.3
>>
>> OLD:
>>        the MA failed record the Measurement Results because it
>>        (unexpectedly) is out of spare memory
>>
>> NEW:
>>        the MA failed_to_record the Measurement Results because it
>>        (unexpectedly) is out of spare memory
> ok
>
>> - Section 5.4.1
>> To match the charter:
>> OLD:
>>     It may also be possible to transfer the information via the MA.
>>
>> NEW:
>>     If the subscriber's service parameters are available to the MAs, 
>> they could be reported
>>     with the Measurement Results in the Report Protocol.
>>
> ok
>
>> - section 6 Deployment considerations
>>     The Appendix has some examples of possible deployment 
>> arrangements of
>>     Measurement Agents and Peers.
>> What does this text tell me? Should I read the appendix before 
>> proceeding?
>> If yes (btw, I think this is the natural reading flow), why is this 
>> an appendix, and not in the core of the document?
>> Note: this appendix contains some nice examples that really glue all 
>> the concepts into practical examples.
>>
>
> ok, i have moved the examples to section 6
>
>> - Appendix A
>> OLD:
>>     Next, we consider Measurement Methods that measure user traffic.
>> NEW:
>>     Next, we consider Measurement Methods that meter the Observed 
>> Traffic Flow.
> ok
>
>> NEW figure A4
>>     +--------+   +----------------+            +--------+      ^
>>     |End user|   |  MA: Monitor   |  Observed  |End user|      |
>>     | or MP  |<--|----------------|--Traffic ->| or MP  | non-LMAP
>>     |        |   |                |  Flow      |        | Scope
>>     +--------+   |                |            +--------+      |
>> ...|................|............................v..
>>                  | LMAP interface |                            ^
>>                  +----------------+                            |
>>                          ^     |                               |
>>              Instruction |     |  Report                       |
>>                          |     +-----------------+             |
>>                          |                       |             |
>>                          |                       v LMAP
>>                    +------------+             +------------+ Scope
>>                    | Controller |             |  Collector |   |
>>                    +------------+             +------------+   v
>>
>>
>>     Figure A4: Schematic of LMAP-based Measurement System,
>>     with a Measurement Agent monitoring traffic
>>
> ok
>
>> - Security Considerations
>> There is a privacy aspects for Observed Traffic Flow (typically the 
>> figure A4), as you mentioned in sections 8.2, 8.3, 8.4.5 (and maybe 
>> some others). FYI. This has been addressed in IPFIX: see 
>> https://tools.ietf.org/html/rfc7011#section-11.8
>>
>
> ok, i added a reference to RFC7011 in section 8.3
>
>> - Question: Have you discussed the ability for LMAP to use sampling 
>> for Observed Traffic Flows? Is this necessary?
>> See http://datatracker.ietf.org/wg/psamp/documents/
>>
>
> The current framework doesnt go deep into the specifics of the 
> different measurement (just what is needed to understand the 
> framework), so i believe this probably is too specific for this 
> document. I dont really have a strong opinion. If you have an specific 
> text you would like to include in the document, feel free to suggest, 
> we will be happy to discuss it.
>
> Regards, marcelo
>
>> Regards, Benoit
>
> _______________________________________________
> lmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lmap