Re: [lmap] AD review of draft-ietf-lmap-framework-10
Benoit Claise <bclaise@cisco.com> Mon, 23 February 2015 08:32 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CB91A0381 for <lmap@ietfa.amsl.com>; Mon, 23 Feb 2015 00:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3h9GtVsvD7N for <lmap@ietfa.amsl.com>; Mon, 23 Feb 2015 00:32:30 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A111A037E for <lmap@ietf.org>; Mon, 23 Feb 2015 00:32:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9476; q=dns/txt; s=iport; t=1424680350; x=1425889950; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xWn86z8T/p63MEcuP+qi57uBjQSGCYpxUNYTAhuh9Yw=; b=gjEOAQKlPxPXf/kPfjmLWMPreGhOqeq+YmGkTzaU8EK7S1MLL6u89hMc BGd20WNhKyA8yLH4/eaIdTa9Dl0xl+4t18821owhiPY8exE1eRPLuA3Dw IwtJVlzwO9WwKwwRwvRyyXkKmLruGR95ZITI3qVgxmVrZQLfbMo1P4za8 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ARBQDg5OpU/xbLJq1bg1haAYMHtk6JQoVuAoFjAQEBAQEBfIQQAQEEIwQLAQUvEQEQCxoCBRYLAgIJAwIBAgFFBgEJAwEHAQGIKw26YJd8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXKEbgeCaIFDAQSFYo1OhWWBGziCXYIuIYh2gz4ig289MQGCQgEBAQ
X-IronPort-AV: E=Sophos;i="5.09,629,1418083200"; d="scan'208";a="358366259"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 23 Feb 2015 08:32:28 +0000
Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1N8WPVZ006695; Mon, 23 Feb 2015 08:32:26 GMT
Message-ID: <54EAE599.5000407@cisco.com>
Date: Mon, 23 Feb 2015 09:32:25 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "marcelo@it.uc3m.es >> marcelo bagnulo braun" <marcelo@it.uc3m.es>, "lmap@ietf.org" <lmap@ietf.org>
References: <54E38787.2090009@cisco.com> <54E9B772.101@neomailbox.ch>
In-Reply-To: <54E9B772.101@neomailbox.ch>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/lmap/2_ACp37JjoUQS4TnCjd3c8dvtrs>
Cc: Radia Perlman <radiaperlman@gmail.com>, "draft-ietf-lmap-framework@tools.ietf.org" <draft-ietf-lmap-framework@tools.ietf.org>
Subject: Re: [lmap] AD review of draft-ietf-lmap-framework-10
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 23 Feb 2015 08:32:32 -0000
Hi Marcelo, Thanks for the quick reaction, and for the new draft version. I'm progressing this document to IETF LC now. Regards, Benoit > 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] AD review of draft-ietf-lmap-framework-10 Benoit Claise
- Re: [lmap] AD review of draft-ietf-lmap-framework… marcelo bagnulo
- [lmap] Fwd: Re: AD review of draft-ietf-lmap-fram… marcelo bagnulo braun
- Re: [lmap] AD review of draft-ietf-lmap-framework… marcelo bagnulo braun
- Re: [lmap] AD review of draft-ietf-lmap-framework… Benoit Claise