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

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

resending with correct source address


-------- Mensaje reenviado --------
Asunto: 	Re: AD review of draft-ietf-lmap-framework-10
Fecha: 	Sun, 22 Feb 2015 12:03:14 +0100
De: 	marcelo bagnulo <[e-mail]>
Para: 	Benoit Claise <[e-mail]>, [e-mail] <[e-mail]>
CC: 	Radia Perlman <[e-mail]>, 
[e-mail] 
<[e-mail]>



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