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

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Feb 2015 19:25:11 +0100

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.

- 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.

- 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.

- Section 2
OLD:

	Messages are transferred over a secure Channel.

NEW:
	Both control and report messages are transferred over a secure Channel.

-

results repository or Results repository?
Please check all instances.

- Figure 1
The Report goes over the Report Channel, not Control Channel

- 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

- 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.

- 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:

- 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

- 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.

- 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.

- Appendix A
OLD:

    Next, we consider Measurement Methods that measure user traffic.

NEW:

    Next, we consider Measurement Methods that meter the Observed Traffic Flow.

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

- 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

- 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/

Regards, Benoit

---

From: marcelo bagnulo <[email-masked]>
Date: Sun, 22 Feb 2015 12:03:14 +0100

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ó:
> Here is my feedback on version 10. Nothing major. I propose to start 
> the IETF LC as soon a new version is posted
>
> Here, in the abstract, it stands for large-scale measurement 
> platforms. Please change it.
>

done

>        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.

>     purpose and measure some metric associated with its transfer.

ok

> 	Both control and report messages are transferred over a secure Channel.

ok

> 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.

> The Report goes over the Report Channel, not Control Channel
ok

> 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:
>
done

> Should we expect a 1:1 mapping between the parameters above and the 
> list that follows?

Right.
I have include both the role and the measurment point in the figure.
>   o  configuration of the Report Channel(s), each of which needs:
ok

>        (unexpectedly) is out of spare memory
ok

>     with the Measurement Results in the Report Protocol.
ok

> 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

>     Next, we consider Measurement Methods that meter the Observed Traffic Flow.
ok

> NEW figure A4
ok

> 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 

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?

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 22 Feb 2015 12:13:29 +0100

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 <[email-masked]>
Para: 	Benoit Claise <[email-masked]>, [email-masked] <[email-masked]>
CC: 	Radia Perlman <[email-masked]>, 
[email-masked] 
<[email-masked]>

Hi,

done

agree, rephrased as:

ok

ok

ok

done

Right.
ok

ok

ok

ok

ok

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 22 Feb 2015 12:16:16 +0100

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ó:
>       gaming consoles), embedded in service provider controlled 
> devices such as set-top
>>           [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
>> If yes (btw, I think this is the natural reading flow), why is this 
>> an appendix, and not in the core of the document?
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Benoit Claise <[email-masked]>
Date: Mon, 23 Feb 2015 09:32:25 +0100

Hi Marcelo,

Thanks for the quick reaction, and for the new draft version.
I'm progressing this document to IETF LC now.

Regards, Benoit
> .