[lmap] Feedback on draft-eardley-lmap-framework

Benoit Claise <bclaise@cisco.com> Wed, 24 July 2013 14:01 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992A511E8219 for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 07:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eEXPv7FqqYG for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 07:01:25 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C1E6711E819E for <lmap@ietf.org>; Wed, 24 Jul 2013 07:01:16 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6OE0c0w029442 for <lmap@ietf.org>; Wed, 24 Jul 2013 16:00:38 +0200 (CEST)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6OE0N6l007983 for <lmap@ietf.org>; Wed, 24 Jul 2013 16:00:33 +0200 (CEST)
Message-ID: <51EFDDE7.5030009@cisco.com>
Date: Wed, 24 Jul 2013 16:00:07 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "lmap@ietf.org" <lmap@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [lmap] Feedback on draft-eardley-lmap-framework
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lmap>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 14:01:29 -0000

Dear authors,

A couple of high level points (next to the ones Dan made)
One of the goal behind this email is to generate discussions, either on 
the list, or during the IETF meeting next week.

-

    It is possible that communications between two Collectors, two
    Controllers and a Controller and Collector may be useful in some use
    cases, perhaps to help a measurement system scale.  Work on such a
    protocol is out of scope of LMAP (?)

There are many aspects to this:
* Report Protocol load balancing, such as Reliable Server Pooling 
(http://datatracker.ietf.org/wg/rserpool/)
* Results deduplication, if the Report Protocol duplicates results to 
multiple collector
* etc...

We need to have simplifying assumptions to start with, otherwise it 
might prove difficult to solve all problems at once.

-  I like the facts that the framework clearly labels the constraints, 
and the items out of scope.

-

   Standardised methods are needed for each metric that is measured.  A
    registry for commonly-used metrics [registry] is also required, so
    that a test can be defined simply by its identifier in the registry.
    The methods and registry would hopefully also be referenced by other
    standards organisations.

    o  Such activities are in scope of the IPPM working group (possibly
       re-chartered) and not LMAP.

IPPM was jut rechartered

Regards, Benoit