From philip.eardley@bt.com Tue Sep 3 09:59:44 2013 Return-Path: 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 43D9E21E804E for ; Tue, 3 Sep 2013 09:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 BNl5EnRUbZAL for ; Tue, 3 Sep 2013 09:59:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9828C21E817C for ; Tue, 3 Sep 2013 09:58:47 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 3 Sep 2013 17:58:34 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Tue, 3 Sep 2013 17:58:34 +0100 From: To: Date: Tue, 3 Sep 2013 17:58:32 +0100 Thread-Topic: LMAP framework issue #1 User-initiated Measurement Tasks Thread-Index: Ac6oxTl43dfkRXB1QZGOg/kNOKXELg== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411B9DEMV67UKRDdoma_" MIME-Version: 1.0 Subject: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 16:59:44 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411B9DEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've now started creating an LMAP framework doc that merges 3 I-Ds (termin= ology and the 2 framework docs) - hoping it could be the basis for a WG doc= - as mentioned in Berlin. One section will be about proposed constraints /assumptions - extending htt= p://tools.ietf.org/html/draft-eardley-lmap-framework-02#section-3 I'm going to send a series of emails to try and capture where I think the d= iscussion got to in Berlin &/or propose text for the I-D &/or generate disc= ussion on open issues. Constraint: User-initiated Measurement Tasks out of scope of LMAP WG We expect LMAP & IPPM functionality to be used for user-initiated Measureme= nt Tasks, but the WG will not define how. There are at least two ways user-= initiation could happen, in outline * a user could somehow (perhaps via a webpage) request the ISP- (or regulat= or-) run measurement system to test his/her line. The ISP (or regulator) Co= ntroller would then send an Instruction to the MA in the usual LMAP way. Th= e Measurement Results could be returned back via the webpage. Note that a u= ser can't directly initiate a Measurement Task on an ISP- (or regulator-) c= ontrolled MA in their home * a user could deploy their own measurement system, with their own MA, Cont= roller and Collector (possibly with all three functions in the same box). T= he user may also want to report Measurement Results to a third party. One p= ossible situation is that the home contains a user-controlled MA and an ISP= -controlled MA; then the test traffic of one MA is treated by the other MA = just like any other user traffic. Note that a single MA is instructed by a = single Controller and is only in one measurement system. For further details see http://www.ietf.org/mail-archive/web/lmap/current/m= sg00714.html and related messages. Comments? Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411B9DEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve now started creating an L= MAP framework doc that merges 3 I-Ds (terminology and the 2 framework docs)= – hoping it could be the basis for a WG doc – as mentioned in = Berlin.

 

One section will b= e about proposed constraints /assumptions – extending http://to= ols.ietf.org/html/draft-eardley-lmap-framework-02#section-3 =

 

I’m going to send a series of = emails to try and capture where I think the discussion got to in Berlin &am= p;/or propose text for the I-D &/or generate discussion on open issues.=

 

Constraint: User-initiat= ed Measurement Tasks out of scope of LMAP WG

We expec= t LMAP & IPPM functionality to be used for user-initiated Measurement T= asks, but the WG will not define how. There are at least two ways user-init= iation could happen, in outline

<= span style=3D'font-family:"Times New Roman","serif"'>* a user could somehow= (perhaps via a webpage) request the ISP- (or regulator-) run measurement s= ystem to test his/her line. The ISP (or regulator) Controller would then se= nd an Instruction to the MA in the usual LMAP way. The Measurement Results = could be returned back via the webpage. Note that a user can’t direct= ly initiate a Measurement Task on an ISP- (or regulator-) controlled MA in = their home

* a user could deploy their own measurement= system, with their own MA, Controller and Collector (possibly with all thr= ee functions in the same box). The user may also want to report Measurement= Results to a third party. One possible situation is that the home contains= a user-controlled MA and an ISP-controlled MA; then the test traffic of on= e MA is treated by the other MA just like any other user traffic. Note that= a single MA is instructed by a single Controller and is only in one measur= ement system.

For further details see http://www.iet= f.org/mail-archive/web/lmap/current/msg00714.html and related messages.=

 

Comments?

Thanks

phil

<= /html>= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411B9DEMV67UKRDdoma_-- From philip.eardley@bt.com Tue Sep 3 10:23:34 2013 Return-Path: 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 EC3A511E80FC for ; Tue, 3 Sep 2013 10:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 BScZ8o8Pm3DD for ; Tue, 3 Sep 2013 10:23:29 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0855E11E8103 for ; Tue, 3 Sep 2013 10:23:27 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 3 Sep 2013 18:23:22 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Tue, 3 Sep 2013 18:23:21 +0100 From: To: Date: Tue, 3 Sep 2013 18:23:21 +0100 Thread-Topic: LMAP Framework issue #2 Admission control and measurement suppression Thread-Index: Ac6oyXIu0tukwmg3RrOoJEp/G27obw== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411BA4EMV67UKRDdoma_" MIME-Version: 1.0 Subject: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 17:23:35 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411BA4EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another issue.... Admission control functionality pre-checks that it is a suitable moment to = carry out a Measurement Task. It is the job of the Measurement Method to de= fine such a pre-check - hence this is in the scope of IPPM rather than LMAP= . Action could include: * the MA checking that there is no cross-traffic (ie that the user isn't a= lready sending traffic) before the Measurement Task starts sending traffic; * the first part of the Measurement Task consisting of the MA asking the M= easurement Peer whether it can send test traffic; * the first part of the Measurement Task consisting of traffic that probes= the path to make sure it isn't overloaded; * the Measurement Task detecting the presence of cross-traffic after the M= A (&/or MP) has started sending traffic. Note that the LMAP WG does not define a generic admission control process, = since the correct approach depends on the particular Measurement Task. This= also means that the framework doesn't define a coordination process betwee= n MAs; whilst a measurement system may define coordinated Measurement Sched= ules across its various MAs, there is no direct coordination between MAs. In addition the Controller may want to send a "suppress" message to some MA= s so that they temporarily stop performing Active Measurement Tasks - perha= ps there is some unexpected network issue and the ISP wants to eliminate in= essential traffic. Since some Measurement Tasks involve the MP sending traf= fic to the MA, so this suggests the MA may sometimes need to send a "suppre= ss" message to the MP. Discussion needed... 1. the Broadband Forum liaison mentioned a generic admission process, but m= y impression is that people no longer think this is needed. Just wanted to = make sure I got that right. 2. I've heard a couple of comments that suppression is needed, but we haven= 't had much discussion - do people agree? 3. the Information Model should discuss how suppression gets recorded in th= e results (perhaps the on-going results get scrapped - perhaps the results = are marked with a warning - perhaps it depends on the metric?) 4. suppress is a bit messy if the MP is sending traffic to the MA (eg downl= oad speed test). One MP may be sending to several MAs. perhaps the suppress= msg should go directly to the MP? Of course if the MP doesn't have lmap fu= nctionality then there's nothing that can be done in any case. Comments? Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411BA4EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another issue….

 

Admission control functionality pre-check= s that it is a suitable moment to carry out a Measurement Task. It is the j= ob of the Measurement Method to define such a pre-check – hence this = is in the scope of IPPM rather than LMAP. Action could include:<= /span>

*  the MA checking that there is no cross-traffic (ie that t= he user isn’t already sending traffic) before the Measurement Task st= arts sending traffic;

*  the first part of the M= easurement Task consisting of the MA asking the Measurement Peer whether it= can send test traffic;

*  the first part of the = Measurement Task consisting of traffic that probes the path to make sure it= isn’t overloaded;

*  the Measurement Task = detecting the presence of cross-traffic after the MA (&/or MP) has star= ted sending traffic.

 

Note= that the LMAP WG does not define a generic admission control process, sinc= e the correct approach depends on the particular Measurement Task. This als= o means that the framework doesn’t define a coordination process betw= een MAs; whilst a measurement system may define coordinated Measurement Sch= edules across its various MAs, there is no direct coordination between MAs.=

 

In addition the Controll= er may want to send a “suppress” message to some MAs so that th= ey temporarily stop performing Active Measurement Tasks – perhaps the= re is some unexpected network issue and the ISP wants to eliminate inessent= ial traffic. Since some Measurement Tasks involve the MP sending traffic to= the MA, so this suggests the MA may sometimes need to send a “suppre= ss” message to the MP.

 <= /p>

Discussion needed…

2. I’ve heard a c= ouple of comments that suppression is needed, but we haven’t had much= discussion – do people agree?

3. the Informatio= n Model should discuss how suppression gets recorded in the results (perhap= s the on-going results get scrapped – perhaps the results are marked = with a warning – perhaps it depends on the metric?)=

4. suppress is a bit messy if the MP is sending traffic to the MA (eg d= ownload speed test). One MP may be sending to several MAs. perhaps the supp= ress msg should go directly to the MP? Of course if the MP doesn’t ha= ve lmap functionality then there’s nothing that can be done in any ca= se.

 

= Comments?<= /span>

Thanks

phil

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411BA4EMV67UKRDdoma_-- From j.schoenwaelder@jacobs-university.de Tue Sep 3 12:38:48 2013 Return-Path: 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 02BE321E804E for ; Tue, 3 Sep 2013 12:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 R3OcefCgKKiE for ; Tue, 3 Sep 2013 12:38:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CB8F411E812F for ; Tue, 3 Sep 2013 12:38:39 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5935020C4B; Tue, 3 Sep 2013 21:38:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XqMNcZWz-WhJ; Tue, 3 Sep 2013 21:38:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B882E20C4A; Tue, 3 Sep 2013 21:38:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 282912832D64; Tue, 3 Sep 2013 21:38:30 +0200 (CEST) Date: Tue, 3 Sep 2013 21:38:30 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20130903193829.GA51677@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 19:38:49 -0000 On Tue, Sep 03, 2013 at 06:23:21PM +0100, philip.eardley@bt.com wrote: > Another issue.... > > Admission control functionality pre-checks that it is a suitable moment to carry out a Measurement Task. It is the job of the Measurement Method to define such a pre-check - hence this is in the scope of IPPM rather than LMAP. Action could include: > * the MA checking that there is no cross-traffic (ie that the user isn't already sending traffic) before the Measurement Task starts sending traffic; > * the first part of the Measurement Task consisting of the MA asking the Measurement Peer whether it can send test traffic; > * the first part of the Measurement Task consisting of traffic that probes the path to make sure it isn't overloaded; > * the Measurement Task detecting the presence of cross-traffic after the MA (&/or MP) has started sending traffic. > > Note that the LMAP WG does not define a generic admission control process, since the correct approach depends on the particular Measurement Task. This also means that the framework doesn't define a coordination process between MAs; whilst a measurement system may define coordinated Measurement Schedules across its various MAs, there is no direct coordination between MAs. I am wondering whether 'admission control' is the right/best term. Ideally, for certain longer running tests, one should not just check before the test whether certain constraints (e.g. no cross traffic) are satisfied but continue checking also during test execution. > In addition the Controller may want to send a "suppress" message to some MAs so that they temporarily stop performing Active Measurement Tasks - perhaps there is some unexpected network issue and the ISP wants to eliminate inessential traffic. Since some Measurement Tasks involve the MP sending traffic to the MA, so this suggests the MA may sometimes need to send a "suppress" message to the MP. > > > Discussion needed... > 1. the Broadband Forum liaison mentioned a generic admission process, but my impression is that people no longer think this is needed. Just wanted to make sure I got that right. I tend to assume that the constraints that need to be satisfied before and during test execution are highly test dependent. Hence, I am not sure a 'generic admission process' is that useful. > 2. I've heard a couple of comments that suppression is needed, but we haven't had much discussion - do people agree? Having a button to quickly and temporarily turn things off is often very useful. I think it is not essential to get started but surely a nice to have feature (could be an LMAP 2.0 feature if it is too hard to do in 1.0). > 3. the Information Model should discuss how suppression gets recorded in the results (perhaps the on-going results get scrapped - perhaps the results are marked with a warning - perhaps it depends on the metric?) Supression to me means tests are not executed and hence there are no results. The logging mechanism should in my view log the beginning/end of suppression. > 4. suppress is a bit messy if the MP is sending traffic to the MA (eg download speed test). One MP may be sending to several MAs. perhaps the suppress msg should go directly to the MP? Of course if the MP doesn't have lmap functionality then there's nothing that can be done in any case. I think the LMAP model is based on the assumption that the controller talks to the MA and the MA initiates and controls the tests. Hence, an MP should not blindly send test traffic to MAs I think. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From paitken@cisco.com Tue Sep 3 14:26:09 2013 Return-Path: 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 6129C21E809B for ; Tue, 3 Sep 2013 14:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KGwjENi8gJuD for ; Tue, 3 Sep 2013 14:26:03 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3B62311E810E for ; Tue, 3 Sep 2013 14:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6393; q=dns/txt; s=iport; t=1378243563; x=1379453163; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=t3nn6luwsj9QxxdSEN+x2jwzSpT0Hexvr6dAlJ062LA=; b=ly9kujNTG6BRJH8Qm+yEcPjyY9J28/BDtDCukgdNGJgMxuVP4tSGkmsm PNZxH/yYW43JlmN8f4aulOE39OKWqPhqZg5xe6Vw3MffBrwVlGqtqOBC8 GYAcOesa1r7QnqxYvsBxI8M4SI/0S/muYN0w6DVYTKJI/9o0JGeFFBOQm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAAVTJlKQ/khM/2dsb2JhbABbgweCOodQuCaBLhZ0giQBAQEDAXgGCwshFg8JAwIBAgFFEAMIAQGHeAa5SI4tgVCEHQOXdYYsizqDIYFw X-IronPort-AV: E=Sophos;i="4.89,1016,1367971200"; d="scan'208,217";a="17250786" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 03 Sep 2013 21:26:01 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r83LPx0e001446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Sep 2013 21:26:00 GMT Received: from [10.61.162.128] ([10.61.162.128]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r83LPwrl005045 for ; Tue, 3 Sep 2013 22:25:59 +0100 (BST) Message-ID: <522653E6.7040101@cisco.com> Date: Tue, 03 Sep 2013 22:25:58 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: lmap@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000607000609000308080000" Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 21:26:09 -0000 This is a multi-part message in MIME format. --------------000607000609000308080000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phil, > Constraint: User-initiated Measurement Tasks out of scope of LMAP WG > > We expect LMAP & IPPM functionality to be used for user-initiated > Measurement Tasks, but the WG will not define how. There are at least > two ways user-initiation could happen, in outline > > * a user could somehow (perhaps via a webpage) request the ISP- (or > regulator-) run measurement system to test his/her line. The ISP (or > regulator) Controller would then send an Instruction to the MA in the > usual LMAP way. The Measurement Results could be returned back via the > webpage. Note that a user can't directly initiate a Measurement Task > on an ISP- (or regulator-) controlled MA in their home > - because the user doesn't own the (single) controller with which the MA is associated. Fine by me. > * a user could deploy their own measurement system, with their own MA, > Controller and Collector (possibly with all three functions in the > same box). The user may also want to report Measurement Results to a > third party. > I seem to recall that the controller / MA / collector were assumed to belong to a single entity - in which case, reporting results to a third party is out of scope. Any number of means could be used to transfer results from your collector to the third party collector - including, pretending that the third-party collector is part of your own network - which raises authentication and security issues. > One possible situation is that the home contains a user-controlled MA > and an ISP-controlled MA; then the test traffic of one MA is treated > by the other MA just like any other user traffic. > This could introduce a problem, depending upon the exact test conditions. See next email. > Note that a single MA is instructed by a single Controller and is only > in one measurement system. > Definitely. P. --------------000607000609000308080000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Phil,


Constraint: User-initiated Measurement Tasks out of scope of LMAP WG

We expect LMAP & IPPM functionality to be used for user-initiated Measurement Tasks, but the WG will not define how. There are at least two ways user-initiation could happen, in outline

* a user could somehow (perhaps via a webpage) request the ISP- (or regulator-) run measurement system to test his/her line. The ISP (or regulator) Controller would then send an Instruction to the MA in the usual LMAP way. The Measurement Results could be returned back via the webpage. Note that a user can’t directly initiate a Measurement Task on an ISP- (or regulator-) controlled MA in their home


- because the user doesn't own the (single) controller with which the MA is associated. Fine by me.


* a user could deploy their own measurement system, with their own MA, Controller and Collector (possibly with all three functions in the same box). The user may also want to report Measurement Results to a third party.


I seem to recall that the controller / MA / collector were assumed to belong to a single entity - in which case, reporting results to a third party is out of scope. Any number of means could be used to transfer results from your collector to the third party collector - including, pretending that the third-party collector is part of your own network - which raises authentication and security issues.


One possible situation is that the home contains a user-controlled MA and an ISP-controlled MA; then the test traffic of one MA is treated by the other MA just like any other user traffic.


This could introduce a problem, depending upon the exact test conditions. See next email.


Note that a single MA is instructed by a single Controller and is only in one measurement system.


Definitely.

P. --------------000607000609000308080000-- From paitken@cisco.com Tue Sep 3 14:27:41 2013 Return-Path: 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 093CB11E8127 for ; Tue, 3 Sep 2013 14:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DAbPcmzlTEs1 for ; Tue, 3 Sep 2013 14:27:35 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id A1F3521F9AD8 for ; Tue, 3 Sep 2013 14:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14091; q=dns/txt; s=iport; t=1378243654; x=1379453254; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=xMS0LGLdaPv8yx7UWqgOzGY5c/Ok7zkk0JPbnSu//gg=; b=ld/1kBKf6nH5jVVaRwd5j3X5CSjJBHg7FhqpYmdz1tXu3ahQmJ5I/d1n FDh+wM8Rm6EAFWH9rdg/8IY2axXOpr5YENmyO7lZCsUSdYyg1NmdGXoT4 qFRhaPXjbGkvXd9NUGwwOAdmd1AaBTjlI7+WqehrnttO9Xy233fXl7Tlu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAAhTJlKQ/khR/2dsb2JhbABbgkNEigq4JoEuFnSCJAEBAQMBLUsBBQsLIRYPCQMCAQIBRRMBBwEBh3gGuUiPdgeEHQOXdYYsizqBY4E+gWck X-IronPort-AV: E=Sophos;i="4.89,1016,1367971200"; d="scan'208,217";a="17725255" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 03 Sep 2013 21:27:33 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r83LRVaI021381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Sep 2013 21:27:31 GMT Received: from [10.61.162.128] ([10.61.162.128]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r83LRUEn005169; Tue, 3 Sep 2013 22:27:30 +0100 (BST) Message-ID: <52265442.1020602@cisco.com> Date: Tue, 03 Sep 2013 22:27:30 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: philip.eardley@bt.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070305090509090009030904" Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 21:27:41 -0000 This is a multi-part message in MIME format. --------------070305090509090009030904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phil, > Another issue.... > > Admission control functionality pre-checks that it is a suitable > moment to carry out a Measurement Task. It is the job of the > Measurement Method to define such a pre-check -- hence this is in the > scope of IPPM rather than LMAP. Action could include: > > * the MA checking that there is no cross-traffic (ie that the user > isn't already sending traffic) before the Measurement Task starts > sending traffic; > > * the first part of the Measurement Task consisting of the MA asking > the Measurement Peer whether it can send test traffic; > > * the first part of the Measurement Task consisting of traffic that > probes the path to make sure it isn't overloaded; > > * the Measurement Task detecting the presence of cross-traffic after > the MA (&/or MP) has started sending traffic. > If there are multiple independent MAs in a single device (or, in close proximity), a race condition could easily occur: Suppose two MAs require no cross traffic for their tests - so both MAs wait for suitably quiescent conditions. Then they both query their MPs to obtain test traffic - at which point each MA sees the other's traffic and aborts. Rinse, repeat... Or, once several MAs have obtained test traffic, the volume causes a CPU or interface overload which makes all the MAs abort. So a certain amount of cooperation may be required between multiple MAs. This may be both necessary and out of scope... > Note that the LMAP WG does not define a generic admission control > process, since the correct approach depends on the particular > Measurement Task. This also means that the framework doesn't define a > coordination process between MAs; whilst a measurement system may > define coordinated Measurement Schedules across its various MAs, there > is no direct coordination between MAs. > > In addition the Controller may want to send a "suppress" message to > some MAs so that they temporarily stop performing Active Measurement > Tasks -- perhaps there is some unexpected network issue and the ISP > wants to eliminate inessential traffic. Since some Measurement Tasks > involve the MP sending traffic to the MA, so this suggests the MA may > sometimes need to send a "suppress" message to the MP. > Definitely. However, the controller should always have an overall picture of what's going on in the network and be co-ordinating activity, so suppression is rarely required. > Discussion needed... > > 1. the Broadband Forum liaison mentioned a generic admission process, > but my impression is that people no longer think this is needed. Just > wanted to make sure I got that right. > > 2. I've heard a couple of comments that suppression is needed, but we > haven't had much discussion -- do people agree? > I believe that it may be useful and should be designed for. > 3. the Information Model should discuss how suppression gets recorded > in the results (perhaps the on-going results get scrapped -- perhaps > the results are marked with a warning -- perhaps it depends on the > metric?) > The MA should abort the test, append a "suppressed" message, and output the results that it has. Potentially the suppression message should have a "and don't report" option. > 4. suppress is a bit messy if the MP is sending traffic to the MA (eg > download speed test). One MP may be sending to several MAs. perhaps > the suppress msg should go directly to the MP? Of course if the MP > doesn't have lmap functionality then there's nothing that can be done > in any case. > The controller might not know which MPs are in use. eg, the test might leave MP selection up to the MA. eg, ping the local DNS server 100 times. P. --------------070305090509090009030904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Phil,

Another issue….

 

Admission control functionality pre-checks that it is a suitable moment to carry out a Measurement Task. It is the job of the Measurement Method to define such a pre-check – hence this is in the scope of IPPM rather than LMAP. Action could include:

*  the MA checking that there is no cross-traffic (ie that the user isn’t already sending traffic) before the Measurement Task starts sending traffic;

*  the first part of the Measurement Task consisting of the MA asking the Measurement Peer whether it can send test traffic;

*  the first part of the Measurement Task consisting of traffic that probes the path to make sure it isn’t overloaded;

*  the Measurement Task detecting the presence of cross-traffic after the MA (&/or MP) has started sending traffic.


If there are multiple independent MAs in a single device (or, in close proximity), a race condition could easily occur:

Suppose two MAs require no cross traffic for their tests - so both MAs wait for suitably quiescent conditions. Then they both query their MPs to obtain test traffic - at which point each MA sees the other's traffic and aborts. Rinse, repeat...

Or, once several MAs have obtained test traffic, the volume causes a CPU or interface overload which makes all the MAs abort.

So a certain amount of cooperation may be required between multiple MAs. This may be both necessary and out of scope...


Note that the LMAP WG does not define a generic admission control process, since the correct approach depends on the particular Measurement Task. This also means that the framework doesn’t define a coordination process between MAs; whilst a measurement system may define coordinated Measurement Schedules across its various MAs, there is no direct coordination between MAs.

 

In addition the Controller may want to send a “suppress” message to some MAs so that they temporarily stop performing Active Measurement Tasks – perhaps there is some unexpected network issue and the ISP wants to eliminate inessential traffic. Since some Measurement Tasks involve the MP sending traffic to the MA, so this suggests the MA may sometimes need to send a “suppress” message to the MP.


Definitely. However, the controller should always have an overall picture of what's going on in the network and be co-ordinating activity, so suppression is rarely required.


Discussion needed…

1. the Broadband Forum liaison mentioned a generic admission process, but my impression is that people no longer think this is needed. Just wanted to make sure I got that right.

2. I’ve heard a couple of comments that suppression is needed, but we haven’t had much discussion – do people agree?


I believe that it may be useful and should be designed for.


3. the Information Model should discuss how suppression gets recorded in the results (perhaps the on-going results get scrapped – perhaps the results are marked with a warning – perhaps it depends on the metric?)


The MA should abort the test, append a "suppressed" message, and output the results that it has. Potentially the suppression message should have a "and don't report" option.


4. suppress is a bit messy if the MP is sending traffic to the MA (eg download speed test). One MP may be sending to several MAs. perhaps the suppress msg should go directly to the MP? Of course if the MP doesn’t have lmap functionality then there’s nothing that can be done in any case.


The controller might not know which MPs are in use. eg, the test might leave MP selection up to the MA. eg, ping the local DNS server 100 times.

P.

--------------070305090509090009030904-- From paitken@cisco.com Tue Sep 3 14:29:25 2013 Return-Path: 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 B953711E8130 for ; Tue, 3 Sep 2013 14:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 ayxOHVMpiH1i for ; Tue, 3 Sep 2013 14:29:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0156011E810E for ; Tue, 3 Sep 2013 14:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1415; q=dns/txt; s=iport; t=1378243760; x=1379453360; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jABEzU8IzuZ0tjInHrr9EKOqTht8J1SbWsE4qdJCM0k=; b=SZg9tsYl02p8fnX74FmsHqV4uFXvQjReQzXcBeUG88OiEnF1p980zjW7 fPmmUf6vzAaKmsOqnAmMDKbj0b2AlzVwKK1fIUzQFkxh5XiZbUL1btGGe V3dfctkc9PoqyNooQwYNeFOtUZXAlCej7k29rNVV5AcOPaqBn9QMDBdts A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAGhUJlKQ/khL/2dsb2JhbABbgwfCMIEuFnSCJAEBAQMBOEEQCw4TJQ8CRgYNAQcBAYd4BrlLj3YHhB0Dl3WGLIs6gWOBPoFnBx0 X-IronPort-AV: E=Sophos;i="4.89,1016,1367971200"; d="scan'208";a="159210709" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Sep 2013 21:29:18 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r83LTGec027103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Sep 2013 21:29:17 GMT Received: from [10.61.162.128] ([10.61.162.128]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r83LTF01005294; Tue, 3 Sep 2013 22:29:16 +0100 (BST) Message-ID: <522654AB.60900@cisco.com> Date: Tue, 03 Sep 2013 22:29:15 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Juergen Schoenwaelder References: <20130903193829.GA51677@elstar.local> In-Reply-To: <20130903193829.GA51677@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 21:29:25 -0000 Juergen, >> 2. I've heard a couple of comments that suppression is needed, but we haven't had much discussion - do people agree? > Having a button to quickly and temporarily turn things off is often > very useful. I think it is not essential to get started but surely a > nice to have feature (could be an LMAP 2.0 feature if it is too hard > to do in 1.0). +1 >> 3. the Information Model should discuss how suppression gets recorded in the results (perhaps the on-going results get scrapped - perhaps the results are marked with a warning - perhaps it depends on the metric?) > Supression to me means tests are not executed and hence there are no > results. The logging mechanism should in my view log the beginning/end > of suppression. Perhaps there are two requirements: "stop+report" versus "suppress" (with no report) ? >> 4. suppress is a bit messy if the MP is sending traffic to the MA (eg download speed test). One MP may be sending to several MAs. perhaps the suppress msg should go directly to the MP? Of course if the MP doesn't have lmap functionality then there's nothing that can be done in any case. > I think the LMAP model is based on the assumption that the controller > talks to the MA and the MA initiates and controls the tests. Hence, an > MP should not blindly send test traffic to MAs I think. +1. The controller shouldn't talk to the MP / MPs. P. From marcelo@it.uc3m.es Wed Sep 4 00:30:13 2013 Return-Path: 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 1CC0511E817D for ; Wed, 4 Sep 2013 00:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 BsRs5IX3B6Kb for ; Wed, 4 Sep 2013 00:30:08 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 15EFC11E8183 for ; Wed, 4 Sep 2013 00:30:07 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4EDAACD07E1 for ; Wed, 4 Sep 2013 09:30:05 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost34.it.uc3m.es (dummyhost25.it.uc3m.es [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 35772CB7811 for ; Wed, 4 Sep 2013 09:30:05 +0200 (CEST) Message-ID: <5226E17E.5060009@it.uc3m.es> Date: Wed, 04 Sep 2013 09:30:06 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lmap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Wed, 04 Sep 2013 09:30:05 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20126.005 Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 07:30:13 -0000 So, my concern here is that in the first option, it seems that the user initiated tests can be controlled by the ISP and the ISP could be aware fo what tests the user is trying to do and react accordingly (suppose the ISP usually caps some type of traffic and when it realizes the user is trying to test for the capacity, it opens the cap). The second option, i think it is the way to go, but as you wrote it it reads a bit weak. I woudl rather a stronger wording, like a MUST or at least a SHOULD (i mean, the user initiated measurement function MUST be availabel in the MA) regards, marcelo El 03/09/13 18:58, philip.eardley@bt.com escribió: > > We’ve now started creating an LMAP framework doc that merges 3 I-Ds > (terminology and the 2 framework docs) – hoping it could be the basis > for a WG doc – as mentioned in Berlin. > > One section will be about proposed constraints /assumptions – > extending > http://tools.ietf.org/html/draft-eardley-lmap-framework-02#section-3 > > I’m going to send a series of emails to try and capture where I think > the discussion got to in Berlin &/or propose text for the I-D &/or > generate discussion on open issues. > > Constraint: User-initiated Measurement Tasks out of scope of LMAP WG > > We expect LMAP & IPPM functionality to be used for user-initiated > Measurement Tasks, but the WG will not define how. There are at least > two ways user-initiation could happen, in outline > > * a user could somehow (perhaps via a webpage) request the ISP- (or > regulator-) run measurement system to test his/her line. The ISP (or > regulator) Controller would then send an Instruction to the MA in the > usual LMAP way. The Measurement Results could be returned back via the > webpage. Note that a user can’t directly initiate a Measurement Task > on an ISP- (or regulator-) controlled MA in their home > > * a user could deploy their own measurement system, with their own MA, > Controller and Collector (possibly with all three functions in the > same box). The user may also want to report Measurement Results to a > third party. One possible situation is that the home contains a > user-controlled MA and an ISP-controlled MA; then the test traffic of > one MA is treated by the other MA just like any other user traffic. > Note that a single MA is instructed by a single Controller and is only > in one measurement system. > > For further details see > http://www.ietf.org/mail-archive/web/lmap/current/msg00714.html and > related messages. > > Comments? > > Thanks > > phil > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From trevor.burbridge@bt.com Wed Sep 4 00:49:29 2013 Return-Path: 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 F33B411E80E3 for ; Wed, 4 Sep 2013 00:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XFAe6tUeRab9 for ; Wed, 4 Sep 2013 00:49:24 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 95DA111E818A for ; Wed, 4 Sep 2013 00:49:23 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 4 Sep 2013 08:49:22 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.149]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 4 Sep 2013 08:49:21 +0100 From: To: , Date: Wed, 4 Sep 2013 08:49:20 +0100 Thread-Topic: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks Thread-Index: Ac6pQJujp7D8A5ruSt2yJbPse4IdiQAAfu+w Message-ID: References: <5226E17E.5060009@it.uc3m.es> In-Reply-To: <5226E17E.5060009@it.uc3m.es> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 07:49:29 -0000 I think both are very valid options. Comments below... >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >marcelo bagnulo braun >Sent: 04 September 2013 08:30 >To: lmap@ietf.org >Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement >Tasks > >So, my concern here is that in the first option, it seems that the user >initiated tests can be controlled by the ISP and the ISP could be aware fo >what tests the user is trying to do and react accordingly (suppose the ISP >usually caps some type of traffic and when it realizes the user is trying = to >test for the capacity, it opens the cap). It is the ISPs measurement system. It is a perfectly valid option for the I= SP to allow the users to use the same measurement system. The scenario you = describe could actually be a benefit since the test traffic is known to the= ISP who will discount this traffic from usage caps. I really don't see any ISP trying to pretend their line speeds etc. are hig= her than they actually are - they wouldn't have to modify the network to do= this - just lie about the result, but I really don't see this as plausible= . >The second option, i think it is the way to go, but as you wrote it it rea= ds a >bit weak. I woudl rather a stronger wording, like a MUST or at least a >SHOULD (i mean, the user initiated measurement function MUST be availabel >in the MA) If this is a separate measurement system there IS a Controller. The user ow= ns that Controller. There will be some management interface to that Control= ler to schedule or request tests, or maybe it's just a standard test schedu= le that is run. The management interface I think doesn't need to be standar= dised. >regards, marcelo > > >El 03/09/13 18:58, philip.eardley@bt.com escribi=F3: >> >> We've now started creating an LMAP framework doc that merges 3 I-Ds >> (terminology and the 2 framework docs) - hoping it could be the basis >> for a WG doc - as mentioned in Berlin. >> >> One section will be about proposed constraints /assumptions - >> extending >> http://tools.ietf.org/html/draft-eardley-lmap-framework-02#section-3 >> >> I'm going to send a series of emails to try and capture where I think >> the discussion got to in Berlin &/or propose text for the I-D &/or >> generate discussion on open issues. >> >> Constraint: User-initiated Measurement Tasks out of scope of LMAP WG >> >> We expect LMAP & IPPM functionality to be used for user-initiated >> Measurement Tasks, but the WG will not define how. There are at least >> two ways user-initiation could happen, in outline >> >> * a user could somehow (perhaps via a webpage) request the ISP- (or >> regulator-) run measurement system to test his/her line. The ISP (or >> regulator) Controller would then send an Instruction to the MA in the >> usual LMAP way. The Measurement Results could be returned back via the >> webpage. Note that a user can't directly initiate a Measurement Task >> on an ISP- (or regulator-) controlled MA in their home >> >> * a user could deploy their own measurement system, with their own MA, >> Controller and Collector (possibly with all three functions in the >> same box). The user may also want to report Measurement Results to a >> third party. One possible situation is that the home contains a >> user-controlled MA and an ISP-controlled MA; then the test traffic of >> one MA is treated by the other MA just like any other user traffic. >> Note that a single MA is instructed by a single Controller and is only >> in one measurement system. >> >> For further details see >> http://www.ietf.org/mail-archive/web/lmap/current/msg00714.html and >> related messages. >> >> Comments? >> >> Thanks >> >> phil >> >> >> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From j.schoenwaelder@jacobs-university.de Wed Sep 4 00:49:40 2013 Return-Path: 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 76CF611E80E3 for ; Wed, 4 Sep 2013 00:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.22 X-Spam-Level: X-Spam-Status: No, score=-103.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 g917NppEgFDR for ; Wed, 4 Sep 2013 00:49:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D95E511E8191 for ; Wed, 4 Sep 2013 00:49:32 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5FD2320C6F; Wed, 4 Sep 2013 09:49:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nhd_nudYNAIu; Wed, 4 Sep 2013 09:49:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71C4D20C4B; Wed, 4 Sep 2013 09:49:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3B2DA2833967; Wed, 4 Sep 2013 09:49:23 +0200 (CEST) Date: Wed, 4 Sep 2013 09:49:22 +0200 From: Juergen Schoenwaelder To: Paul Aitken Message-ID: <20130904074922.GD52962@elstar.local> Mail-Followup-To: Paul Aitken , philip.eardley@bt.com, lmap@ietf.org References: <52265442.1020602@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52265442.1020602@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 07:49:40 -0000 On Tue, Sep 03, 2013 at 10:27:30PM +0100, Paul Aitken wrote: > > If there are multiple independent MAs in a single device (or, in > close proximity), a race condition could easily occur: > > Suppose two MAs require no cross traffic for their tests - so both > MAs wait for suitably quiescent conditions. Then they both query > their MPs to obtain test traffic - at which point each MA sees the > other's traffic and aborts. Rinse, repeat... > > Or, once several MAs have obtained test traffic, the volume causes a > CPU or interface overload which makes all the MAs abort. > > So a certain amount of cooperation may be required between multiple > MAs. This may be both necessary and out of scope... > There will be many other things that can interfere with the tests executed by an MA - not just other MAs. To make the system robust, MAs and more specifically the tests need to carefully check as much as is reasonable that the measurements are not impacted by lack of local resources or network resources. In other words, putting effort on coordination between multiple MAs while lots of other stuff can still interfere with measurements seems somewhat like a waste of time to me. If a test is sensitive to local cross traffic, measure cross traffic and discard or label results that may be wrong. If a test requires sufficient CPU cycles, check the system load or the amount of time measurement processes are blocked waiting for the CPU. If a test is sensitive to network disruptions, check that the link status and network configuration did not change during test execution. And in general, collect sufficient samples such that any sufficient statistical evidence can be produced even if there are occasional measurement errors an even well written test won't be able to detect. My point is that spending effort to coordinate multiple MAs while everything else happening around an MA remains uncoordinated and uncontrolled may not be an efficient use of resources. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From marcelo@it.uc3m.es Wed Sep 4 01:20:31 2013 Return-Path: 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 4010F11E80E6 for ; Wed, 4 Sep 2013 01:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.921 X-Spam-Level: X-Spam-Status: No, score=-105.921 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, FB_ROLLER_IS_T=1.357, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 LxgTzKrkD8ln for ; Wed, 4 Sep 2013 01:20:13 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id D0D4611E8131 for ; Wed, 4 Sep 2013 01:20:11 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 01C9FCD6426; Wed, 4 Sep 2013 10:20:02 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost34.it.uc3m.es (dummyhost25.it.uc3m.es [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id E836FC356EE; Wed, 4 Sep 2013 10:20:01 +0200 (CEST) Message-ID: <5226ED32.9090604@it.uc3m.es> Date: Wed, 04 Sep 2013 10:20:02 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: trevor.burbridge@bt.com References: <5226E17E.5060009@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Wed, 04 Sep 2013 10:20:01 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20126.005 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 08:20:31 -0000 El 04/09/13 09:49, trevor.burbridge@bt.com escribió: > I think both are very valid options. Comments below... > >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >> marcelo bagnulo braun >> Sent: 04 September 2013 08:30 >> To: lmap@ietf.org >> Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement >> Tasks >> >> So, my concern here is that in the first option, it seems that the user >> initiated tests can be controlled by the ISP and the ISP could be aware fo >> what tests the user is trying to do and react accordingly (suppose the ISP >> usually caps some type of traffic and when it realizes the user is trying to >> test for the capacity, it opens the cap). > It is the ISPs measurement system. It is a perfectly valid option for the ISP to allow the users to use the same measurement system. The scenario you describe could actually be a benefit since the test traffic is known to the ISP who will discount this traffic from usage caps. > > I really don't see any ISP trying to pretend their line speeds etc. are higher than they actually are - they wouldn't have to modify the network to do this - just lie about the result, but I really don't see this as plausible. > mmm, i think it is a legitimate need that the user can do measurements that are not supervised by the ISP. >> The second option, i think it is the way to go, but as you wrote it it reads a >> bit weak. I woudl rather a stronger wording, like a MUST or at least a >> SHOULD (i mean, the user initiated measurement function MUST be availabel >> in the MA) > If this is a separate measurement system there IS a Controller. The user owns that Controller. There will be some management interface to that Controller to schedule or request tests, or maybe it's just a standard test schedule that is run. The management interface I think doesn't need to be standardised. the way i see it is that the controller is the user itself i.e. the user interface. I mean, something like speedtest, right? The user clicks a button in the GUI and it triggers a test. The wording here would simply say that the user must have access to a UI with the MA and that it will allow the user to initate measurements. Regards, marcelo >> regards, marcelo >> >> >> El 03/09/13 18:58, philip.eardley@bt.com escribió: >>> We've now started creating an LMAP framework doc that merges 3 I-Ds >>> (terminology and the 2 framework docs) - hoping it could be the basis >>> for a WG doc - as mentioned in Berlin. >>> >>> One section will be about proposed constraints /assumptions - >>> extending >>> http://tools.ietf.org/html/draft-eardley-lmap-framework-02#section-3 >>> >>> I'm going to send a series of emails to try and capture where I think >>> the discussion got to in Berlin &/or propose text for the I-D &/or >>> generate discussion on open issues. >>> >>> Constraint: User-initiated Measurement Tasks out of scope of LMAP WG >>> >>> We expect LMAP & IPPM functionality to be used for user-initiated >>> Measurement Tasks, but the WG will not define how. There are at least >>> two ways user-initiation could happen, in outline >>> >>> * a user could somehow (perhaps via a webpage) request the ISP- (or >>> regulator-) run measurement system to test his/her line. The ISP (or >>> regulator) Controller would then send an Instruction to the MA in the >>> usual LMAP way. The Measurement Results could be returned back via the >>> webpage. Note that a user can't directly initiate a Measurement Task >>> on an ISP- (or regulator-) controlled MA in their home >>> >>> * a user could deploy their own measurement system, with their own MA, >>> Controller and Collector (possibly with all three functions in the >>> same box). The user may also want to report Measurement Results to a >>> third party. One possible situation is that the home contains a >>> user-controlled MA and an ISP-controlled MA; then the test traffic of >>> one MA is treated by the other MA just like any other user traffic. >>> Note that a single MA is instructed by a single Controller and is only >>> in one measurement system. >>> >>> For further details see >>> http://www.ietf.org/mail-archive/web/lmap/current/msg00714.html and >>> related messages. >>> >>> Comments? >>> >>> Thanks >>> >>> phil >>> >>> >>> >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap From marcelo@it.uc3m.es Wed Sep 4 01:22:52 2013 Return-Path: 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 C2F9E11E818B for ; Wed, 4 Sep 2013 01:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.373 X-Spam-Level: X-Spam-Status: No, score=-106.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 If2wC+Zp96S9 for ; Wed, 4 Sep 2013 01:22:46 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 1722521F8B07 for ; Wed, 4 Sep 2013 01:22:45 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0455AFA7F2E for ; Wed, 4 Sep 2013 10:22:41 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost34.it.uc3m.es (dummyhost25.it.uc3m.es [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id E1DEC9D44FD for ; Wed, 4 Sep 2013 10:22:40 +0200 (CEST) Message-ID: <5226EDD1.5040400@it.uc3m.es> Date: Wed, 04 Sep 2013 10:22:41 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lmap@ietf.org References: <522653E6.7040101@cisco.com> In-Reply-To: <522653E6.7040101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Wed, 04 Sep 2013 10:22:40 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20126.005 X-TM-AS-Result: No--4.483-7.0-31-1 X-imss-scan-details: No--4.483-7.0-31-1 Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 08:22:52 -0000 El 03/09/13 23:25, Paul Aitken escribió: > > > >> * a user could deploy their own measurement system, with their own >> MA, Controller and Collector (possibly with all three functions in >> the same box). The user may also want to report Measurement Results >> to a third party. >> > > I seem to recall that the controller / MA / collector were assumed to > belong to a single entity - in which case, reporting results to a > third party is out of scope. Any number of means could be used to > transfer results from your collector to the third party collector - > including, pretending that the third-party collector is part of your > own network - which raises authentication and security issues. > right. From my perspective, the user intiated MA function is just another user application generating traffic in the user network and should be treated as such. does that makes sense? Regards, marcelo > >> One possible situation is that the home contains a user-controlled MA >> and an ISP-controlled MA; then the test traffic of one MA is treated >> by the other MA just like any other user traffic. >> > > This could introduce a problem, depending upon the exact test > conditions. See next email. > > >> Note that a single MA is instructed by a single Controller and is >> only in one measurement system. >> > > Definitely. > > P. > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From marcelo@it.uc3m.es Wed Sep 4 01:52:34 2013 Return-Path: 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 A666721F9E99 for ; Wed, 4 Sep 2013 01:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.429 X-Spam-Level: X-Spam-Status: No, score=-106.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0SBXNfro7XLx for ; Wed, 4 Sep 2013 01:52:30 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id ACEC821F9E89 for ; Wed, 4 Sep 2013 01:52:29 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E53F2CD60CD for ; Wed, 4 Sep 2013 10:52:27 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost34.it.uc3m.es (dummyhost25.it.uc3m.es [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id D90A6C35806 for ; Wed, 4 Sep 2013 10:52:27 +0200 (CEST) Message-ID: <5226F4CB.1050403@it.uc3m.es> Date: Wed, 04 Sep 2013 10:52:27 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lmap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Wed, 04 Sep 2013 10:52:27 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20126.006 Subject: Re: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 08:52:34 -0000 Hi, comments below... El 03/09/13 19:23, philip.eardley@bt.com escribió: > > Another issue…. > > Admission control functionality pre-checks that it is a suitable > moment to carry out a Measurement Task. It is the job of the > Measurement Method to define such a pre-check – hence this is in the > scope of IPPM rather than LMAP. Action could include: > > * the MA checking that there is no cross-traffic (ie that the user > isn’t already sending traffic) before the Measurement Task starts > sending traffic; > > * the first part of the Measurement Task consisting of the MA asking > the Measurement Peer whether it can send test traffic; > > * the first part of the Measurement Task consisting of traffic that > probes the path to make sure it isn’t overloaded; > > * the Measurement Task detecting the presence of cross-traffic after > the MA (&/or MP) has started sending traffic. > > Note that the LMAP WG does not define a generic admission control > process, since the correct approach depends on the particular > Measurement Task. This also means that the framework doesn’t define a > coordination process between MAs; whilst a measurement system may > define coordinated Measurement Schedules across its various MAs, there > is no direct coordination between MAs. > My take is that this is test/measurement specific and should be taken care of in IPPM when each metric is defined. > In addition the Controller may want to send a “suppress” message to > some MAs so that they temporarily stop performing Active Measurement > Tasks – perhaps there is some unexpected network issue and the ISP > wants to eliminate inessential traffic. Since some Measurement Tasks > involve the MP sending traffic to the MA, so this suggests the MA may > sometimes need to send a “suppress” message to the MP. > I agree we need this. We had a discussion about this a while ago and one specific issue that i found very useful is to distinguish between measurements that are running and measurements that are schedulled to run. Suppose you have schedulled to run 10 TCP throughput tests that last 5 seconds each and they are to be executed every 5 minutes. Suppose that at time T1 the MA is running the first of the TCP throuput tests. Suppose that at time T1 we send the suppress message: what are expecting to suppress? a- abort the ongoing test and suppress the next 9 tests, or, b- finnish the ongoing test and suppress the next 9 tests I think b is easy, b not so much. > Discussion needed… > > 1. the Broadband Forum liaison mentioned a generic admission process, > but my impression is that people no longer think this is needed. Just > wanted to make sure I got that right. > While i see Paul's argumet for needing this, i would expect that in general metrics will have a random delay to start that will solve some of these issues. So, i think i dont think i see too much value in a generic mechanism > 2. I’ve heard a couple of comments that suppression is needed, but we > haven’t had much discussion – do people agree? > agree we need this, please see the discussion above on the timescales, to nail down exactly what we need. > 3. the Information Model should discuss how suppression gets recorded > in the results (perhaps the on-going results get scrapped – perhaps > the results are marked with a warning – perhaps it depends on the metric?) > I think this fits into the logging > 4. suppress is a bit messy if the MP is sending traffic to the MA (eg > download speed test). One MP may be sending to several MAs. perhaps > the suppress msg should go directly to the MP? Of course if the MP > doesn’t have lmap functionality then there’s nothing that can be done > in any case. > mmm, i think the MP should not talk to the controller. It is cleaner this way. Usually, the MA should be able to send an cancel message to the MP (like a TCP RST) and abort the measurement, no? Regards, marcelo > Comments? > > Thanks > > phil > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Wed Sep 4 02:27:37 2013 Return-Path: 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 82AC121F9BD0 for ; Wed, 4 Sep 2013 02:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_00=-2.599, FB_ROLLER_IS_T=1.357, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 9fmulMJRFI+1 for ; Wed, 4 Sep 2013 02:27:32 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id A7EA421F8DA3 for ; Wed, 4 Sep 2013 02:26:57 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 4 Sep 2013 10:26:55 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Wed, 4 Sep 2013 10:26:55 +0100 From: To: , Date: Wed, 4 Sep 2013 10:26:53 +0100 Thread-Topic: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks Thread-Index: Ac6pR6WRiNqRyo+XR86LJJiTqhIhDAACDimQ Message-ID: References: <5226E17E.5060009@it.uc3m.es> <5226ED32.9090604@it.uc3m.es> In-Reply-To: <5226ED32.9090604@it.uc3m.es> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 09:27:37 -0000 Thanks for the comments - conclusion so far I think the text needs to be cl= arified:- - make sure it's clear these are both possibilities, with various pros and = cons - clarify that in case 2 there'd be a GUI or mgt interface to request tests= and see results (just as this is mentioned for case 1) - clarify that in case 2 - if a user reports Measurement Results to a third= party, these would be sent by the Collector and not direct from the MA > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > marcelo bagnulo braun > Sent: 04 September 2013 09:20 > To: Burbridge,T,Trevor,TUB8 R > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement > Tasks >=20 > El 04/09/13 09:49, trevor.burbridge@bt.com escribi=F3: > > I think both are very valid options. Comments below... > > > >> -----Original Message----- > >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > >> Of marcelo bagnulo braun > >> Sent: 04 September 2013 08:30 > >> To: lmap@ietf.org > >> Subject: Re: [lmap] LMAP framework issue #1 User-initiated > >> Measurement Tasks > >> > >> So, my concern here is that in the first option, it seems that the > >> user initiated tests can be controlled by the ISP and the ISP could > >> be aware fo what tests the user is trying to do and react > accordingly > >> (suppose the ISP usually caps some type of traffic and when it > >> realizes the user is trying to test for the capacity, it opens the > cap). > > It is the ISPs measurement system. It is a perfectly valid option for > the ISP to allow the users to use the same measurement system. The > scenario you describe could actually be a benefit since the test > traffic is known to the ISP who will discount this traffic from usage > caps. > > > > I really don't see any ISP trying to pretend their line speeds etc. > are higher than they actually are - they wouldn't have to modify the > network to do this - just lie about the result, but I really don't see > this as plausible. > > >=20 > mmm, i think it is a legitimate need that the user can do measurements > that are not supervised by the ISP. >=20 >=20 > >> The second option, i think it is the way to go, but as you wrote it > it reads a > >> bit weak. I woudl rather a stronger wording, like a MUST or at least > a > >> SHOULD (i mean, the user initiated measurement function MUST be > availabel > >> in the MA) > > If this is a separate measurement system there IS a Controller. The > user owns that Controller. There will be some management interface to > that Controller to schedule or request tests, or maybe it's just a > standard test schedule that is run. The management interface I think > doesn't need to be standardised. >=20 > the way i see it is that the controller is the user itself i.e. the > user > interface. I mean, something like speedtest, right? The user clicks a > button in the GUI and it triggers a test. The wording here would simply > say that the user must have access to a UI with the MA and that it will > allow the user to initate measurements. >=20 > Regards, marcelo >=20 >=20 > >> regards, marcelo > >> > >> > >> El 03/09/13 18:58, philip.eardley@bt.com escribi=F3: > >>> We've now started creating an LMAP framework doc that merges 3 I-Ds > >>> (terminology and the 2 framework docs) - hoping it could be the > basis > >>> for a WG doc - as mentioned in Berlin. > >>> > >>> One section will be about proposed constraints /assumptions - > >>> extending > >>> http://tools.ietf.org/html/draft-eardley-lmap-framework-02#section- > 3 > >>> > >>> I'm going to send a series of emails to try and capture where I > think > >>> the discussion got to in Berlin &/or propose text for the I-D &/or > >>> generate discussion on open issues. > >>> > >>> Constraint: User-initiated Measurement Tasks out of scope of LMAP > WG > >>> > >>> We expect LMAP & IPPM functionality to be used for user-initiated > >>> Measurement Tasks, but the WG will not define how. There are at > least > >>> two ways user-initiation could happen, in outline > >>> > >>> * a user could somehow (perhaps via a webpage) request the ISP- (or > >>> regulator-) run measurement system to test his/her line. The ISP > (or > >>> regulator) Controller would then send an Instruction to the MA in > the > >>> usual LMAP way. The Measurement Results could be returned back via > the > >>> webpage. Note that a user can't directly initiate a Measurement > Task > >>> on an ISP- (or regulator-) controlled MA in their home > >>> > >>> * a user could deploy their own measurement system, with their own > MA, > >>> Controller and Collector (possibly with all three functions in the > >>> same box). The user may also want to report Measurement Results to > a > >>> third party. One possible situation is that the home contains a > >>> user-controlled MA and an ISP-controlled MA; then the test traffic > of > >>> one MA is treated by the other MA just like any other user traffic. > >>> Note that a single MA is instructed by a single Controller and is > only > >>> in one measurement system. > >>> > >>> For further details see > >>> http://www.ietf.org/mail-archive/web/lmap/current/msg00714.html and > >>> related messages. > >>> > >>> Comments? > >>> > >>> Thanks > >>> > >>> phil > >>> > >>> > >>> > >>> _______________________________________________ > >>> lmap mailing list > >>> lmap@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lmap > >> _______________________________________________ > >> lmap mailing list > >> lmap@ietf.org > >> https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From paitken@cisco.com Wed Sep 4 02:36:11 2013 Return-Path: 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 91D2011E819B for ; Wed, 4 Sep 2013 02:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 7ElY6+ix7USl for ; Wed, 4 Sep 2013 02:36:03 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 68EC211E812A for ; Wed, 4 Sep 2013 02:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=738; q=dns/txt; s=iport; t=1378287363; x=1379496963; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bv+ZyH8ufxU8mPXD6kw/rQ6KeAvHKPZQMJ2LI9xuoPY=; b=dCwsihLjvUM4s/x2xotvPeF/G8sTAdsX59nc6Jx//aPT6RbMumzO9PbH NuLrdpT7Hp5qODEcGMIW1iowqYB8ZVFwNopyPu8dCjplexm2YpD/5eEAr aL5qXIF5WWJV2qRo+PRueZqX8Z9ceI0jBWTbvW9gqDk8RkMLE2dvXE+Cf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAGH+JlKQ/khM/2dsb2JhbABagweCO4EsvlKBJBZ0giQBAQEDAThAAQULCyEWBAsJAwIBAgFFEwEFAgEBh3gGuUOOLYFJBxaEBwOXdYYsizqBY4E+gXA X-IronPort-AV: E=Sophos;i="4.89,1020,1367971200"; d="scan'208";a="86388743" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 04 Sep 2013 09:36:02 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r849ZxV7017177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Sep 2013 09:35:59 GMT Received: from [144.254.153.55] (dhcp-144-254-153-55.cisco.com [144.254.153.55]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r849ZwWB005466; Wed, 4 Sep 2013 10:35:59 +0100 (BST) Message-ID: <5226FEFE.8050804@cisco.com> Date: Wed, 04 Sep 2013 10:35:58 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: philip.eardley@bt.com References: <5226E17E.5060009@it.uc3m.es> <5226ED32.9090604@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: marcelo@it.uc3m.es, trevor.burbridge@bt.com, lmap@ietf.org Subject: Re: [lmap] [Sender: lmap-bounces@ietf.org] Re: LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 09:36:11 -0000 Phil, > Thanks for the comments - conclusion so far I think the text needs to be clarified:- > > - make sure it's clear these are both possibilities, with various pros and cons > - clarify that in case 2 there'd be a GUI or mgt interface to request tests and see results (just as this is mentioned for case 1) Say no more than it's some out-of-scope mechanism. It could be an email, SMS, intervention of local politician... LMAP doesn't know and doesn't care, as long as the test sequence is initiated from the single controller which is associated with the MA. > - clarify that in case 2 - if a user reports Measurement Results to a third party, these would be sent by the Collector and not direct from the MA P. From philip.eardley@bt.com Wed Sep 4 02:50:27 2013 Return-Path: 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 C94E411E812A for ; Wed, 4 Sep 2013 02:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.386 X-Spam-Level: X-Spam-Status: No, score=-103.386 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 IRpuzGNqSKZM for ; Wed, 4 Sep 2013 02:50:21 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4B64011E80E3 for ; Wed, 4 Sep 2013 02:50:20 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 4 Sep 2013 10:50:13 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 4 Sep 2013 10:50:13 +0100 From: To: , Date: Wed, 4 Sep 2013 10:50:11 +0100 Thread-Topic: [lmap] LMAP Framework issue #2 Admission control and measurement suppression Thread-Index: Ac6pTBtkORmQkyh6SmOZSiJpnh+MaQABaikw Message-ID: References: <5226F4CB.1050403@it.uc3m.es> In-Reply-To: <5226F4CB.1050403@it.uc3m.es> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 09:50:27 -0000 > > In addition the Controller may want to send a "suppress" message to > > some MAs so that they temporarily stop performing Active Measurement > > Tasks - perhaps there is some unexpected network issue and the ISP > > wants to eliminate inessential traffic. Since some Measurement Tasks > > involve the MP sending traffic to the MA, so this suggests the MA may > > sometimes need to send a "suppress" message to the MP. > > >=20 > I agree we need this. >=20 > We had a discussion about this a while ago and one specific issue that > i found very useful is to distinguish between measurements that are > running and measurements that are schedulled to run. >=20 > Suppose you have schedulled to run 10 TCP throughput tests that last 5 > seconds each and they are to be executed every 5 minutes. >=20 > Suppose that at time T1 the MA is running the first of the TCP throuput > tests. >=20 > Suppose that at time T1 we send the suppress message: what are > expecting to suppress? > a- abort the ongoing test and suppress the next 9 tests, or, > b- finnish the ongoing test and suppress the next 9 tests >=20 > I think b is easy, b not so much. [phil] this is a very good point. Assuming you mean "b is easy, a not so much" - I agree=20 Would it be a reasonable target is for suppression to solve b, but in gener= al not a (perhaps it would be possible for some tests, but not a general ca= pability)? From bs7652@att.com Wed Sep 4 13:42:20 2013 Return-Path: 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 1D5C611E81F3 for ; Wed, 4 Sep 2013 13:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DTVtPQ+89h8L for ; Wed, 4 Sep 2013 13:42:13 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 13EFA11E813B for ; Wed, 4 Sep 2013 13:42:12 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 52b97225.61c0d940.1808339.00-514.4988480.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 04 Sep 2013 20:42:13 +0000 (UTC) X-MXL-Hash: 52279b2525980c83-9fbe725f69d966ea40bade5a6fd392ef165bd3ca Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 91b97225.0.1808269.00-278.4988244.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 04 Sep 2013 20:42:02 +0000 (UTC) X-MXL-Hash: 52279b1a44d0b160-dde22fb86b4fea26a8f52943925d33aba7a73aa1 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r84Kg0iY028067; Wed, 4 Sep 2013 16:42:00 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r84Kfh7n027881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Sep 2013 16:41:56 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 4 Sep 2013 20:41:33 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0123.003; Wed, 4 Sep 2013 16:41:34 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "marcelo@it.uc3m.es" , "trevor.burbridge@bt.com" Thread-Topic: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks Thread-Index: Ac6oxTl43dfkRXB1QZGOg/kNOKXELgAnOE4AAACr9QAAARJ7AAACVbCAAA7LiaA= Date: Wed, 4 Sep 2013 20:41:32 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113035535C@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <5226E17E.5060009@it.uc3m.es> <5226ED32.9090604@it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.245.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=Ft+yCRXq c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=Ju6hs7-_pf0A:10 a=4gb0uSXQ3I0A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=gmrnAUO5hakA:10 a=P9nY1-i13DXTg4nHQuYA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 20:42:20 -0000 > - clarify that in case 2 - if a user reports Measurement Results to a thi= rd party, > these would be sent by the Collector and not direct from the MA I don't see a need to say this. If the user has configured the results to b= e sent to a 3rd party, then that should be an easy thing to describe. This = doesn't change the information model, doesn't change the list of potential = Collector protocols, nor the data models for those protocols. But it does mean we need to say something about such an MA making sure the = user has the choice and allowing the user to suppress sending of any info t= he user considers private. I think this is a worthwhile statement. I suppose, though, that since the Collector can be collocated with the MA, = we could make the case of it being the collocated Collector sending the dat= a along, and not the MA. That seems like an attempt to dodge making the sta= tement about user choice and suppression for privacy. Barbara From Michael.K.Bugenhagen@centurylink.com Wed Sep 4 14:45:44 2013 Return-Path: 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 BF37321F9AAE for ; Wed, 4 Sep 2013 14:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 7I+yEwKNyJsr for ; Wed, 4 Sep 2013 14:45:37 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0F221F969F for ; Wed, 4 Sep 2013 14:45:30 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r84LjHAK000701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Sep 2013 15:45:17 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 4D8CC1E0078; Wed, 4 Sep 2013 16:45:12 -0500 (CDT) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 0DCA81E0073; Wed, 4 Sep 2013 16:45:12 -0500 (CDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r84LjBqG018006; Wed, 4 Sep 2013 15:45:11 -0600 (MDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r84LjAtr016996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 15:45:11 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.02.0318.001; Wed, 4 Sep 2013 16:45:06 -0500 From: "Bugenhagen, Michael K" To: "'STARK, BARBARA H'" , "philip.eardley@bt.com" , "marcelo@it.uc3m.es" , "trevor.burbridge@bt.com" Thread-Topic: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks Thread-Index: Ac6oxTl43dfkRXB1QZGOg/kNOKXELgAraTAAAACr9QAAARJ7AAACVbCAABV3ZgAACFNoAA== Date: Wed, 4 Sep 2013 21:45:06 +0000 Message-ID: References: <5226E17E.5060009@it.uc3m.es> <5226ED32.9090604@it.uc3m.es> <2D09D61DDFA73D4C884805CC7865E6113035535C@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113035535C@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 21:45:45 -0000 The initial drawings I have seem decompose the MA from a scheduler and coll= ector - However I think Barbara is correct, a customer MA should be a "MA applicati= on"... BUT that is not LMAP it's a customer home test MA not part of a lar= ger system. So are we discussing a Large scale, or a Home testing component... or both = and how they fit together? Just doing a logic check.. Mike -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STA= RK, BARBARA H Sent: Wednesday, September 04, 2013 3:42 PM To: philip.eardley@bt.com; marcelo@it.uc3m.es; trevor.burbridge@bt.com Cc: lmap@ietf.org Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Task= s > - clarify that in case 2 - if a user reports Measurement Results to a=20 > third party, these would be sent by the Collector and not direct from=20 > the MA I don't see a need to say this. If the user has configured the results to b= e sent to a 3rd party, then that should be an easy thing to describe. This = doesn't change the information model, doesn't change the list of potential = Collector protocols, nor the data models for those protocols. But it does mean we need to say something about such an MA making sure the = user has the choice and allowing the user to suppress sending of any info t= he user considers private. I think this is a worthwhile statement. I suppose, though, that since the Collector can be collocated with the MA, = we could make the case of it being the collocated Collector sending the dat= a along, and not the MA. That seems like an attempt to dodge making the sta= tement about user choice and suppression for privacy. Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Wed Sep 4 15:36:45 2013 Return-Path: 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 EDE0611E8116 for ; Wed, 4 Sep 2013 15:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 pC3ouN7ZvtPw for ; Wed, 4 Sep 2013 15:36:31 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id D958511E810E for ; Wed, 4 Sep 2013 15:36:30 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id ee5b7225.2aaac6803940.1880688.00-588.5189044.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 04 Sep 2013 22:36:30 +0000 (UTC) X-MXL-Hash: 5227b5ee0c4662ad-5cefb80f06cbdba3e2f2bceeb3fafcc01be22bd9 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ae5b7225.0.1880663.00-406.5188970.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 04 Sep 2013 22:36:28 +0000 (UTC) X-MXL-Hash: 5227b5ec66a0498f-13a7ea7e4d7acb750ff5c7491faf816faa4069b4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r84MaQC4003418; Wed, 4 Sep 2013 18:36:26 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r84MaKBm003371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Sep 2013 18:36:23 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (GAALPA1MSGHUB9B.itservices.sbc.com [130.8.36.88]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 4 Sep 2013 22:36:13 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.03.0123.003; Wed, 4 Sep 2013 18:36:13 -0400 From: "STARK, BARBARA H" To: "Bugenhagen, Michael K" , "philip.eardley@bt.com" , "marcelo@it.uc3m.es" , "trevor.burbridge@bt.com" Thread-Topic: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks Thread-Index: Ac6oxTl43dfkRXB1QZGOg/kNOKXELgAnOE4AAACr9QAAARJ7AAACVbCAAA7LiaAACvyiAAAHetgg Date: Wed, 4 Sep 2013 22:36:12 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130355452@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <5226E17E.5060009@it.uc3m.es> <5226ED32.9090604@it.uc3m.es> <2D09D61DDFA73D4C884805CC7865E6113035535C@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.245.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=Ft+yCRXq c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=Ju6hs7-_pf0A:10 a=4gb0uSXQ3I0A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=gmrnAUO5hakA:10 a=M9Jy7bmyn0SyXV6_odsA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 22:36:45 -0000 > However I think Barbara is correct, a customer MA should be a "MA > application"... BUT that is not LMAP it's a customer home test MA not pa= rt of > a larger system. >=20 > So are we discussing a Large scale, or a Home testing component... or bot= h > and how they fit together? >=20 > Just doing a logic check.. I was thinking of a MA that the customer downloads onto a customer-owned de= vice that tests the Internet connection. It may test against the same MPs b= eing used by entities that publish provider performance statistics. It may = even be provided by such an entity. I'm not thinking of a MA that just test= s the home network. I'm not thinking of how they fit together.=20 If it can test against a MP, is controlled by a single entity, and can pote= ntially report its info, then (1) I don't see where having it in scope adds= much complexity, and (2) by having it in scope, that means things can be s= aid about it. For example, by having it in scope, it's possible to provide = it with guidance around how to interpret results and how to get and use ser= vice attributes and how to play nice with others. And how to ensure custome= r privacy. When something is out of scope, there's no ability to say anything about it= . If this customer-controlled MA is going to play in the same sandbox with al= l the other little MAs, I'd prefer for it to abide by sandbox etiquette. Barbara From philip.eardley@bt.com Thu Sep 5 03:13:34 2013 Return-Path: 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 AA48421E80ED for ; Thu, 5 Sep 2013 03:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.415 X-Spam-Level: X-Spam-Status: No, score=-103.415 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 IcJoHecdw0eN for ; Thu, 5 Sep 2013 03:13:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 57B2D21F9BF3 for ; Thu, 5 Sep 2013 03:13:26 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 5 Sep 2013 11:13:23 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 5 Sep 2013 11:13:23 +0100 From: To: Date: Thu, 5 Sep 2013 11:13:22 +0100 Thread-Topic: LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: Ac6qHSnY0Wl5eTQJRRK1dMtuO0X0Fg== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411E3AEMV67UKRDdoma_" MIME-Version: 1.0 Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 10:13:35 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411E3AEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411E3AEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another issue:<= /o:p>

There is no negotiation between the MA and= Controller - the Controller simply sends the Instruction to the MA, with t= he details of the Measurement Tasks to perform.

In general we expect that the measurement system understands th= e capabilities of its MAs (probably there are only one or a few classes of = MA), so negotiation about the MA’s capabilities would have little ben= efit. It would also add complexity to the MA, Controller and Control Protoc= ol.

 

It is possible that the MA can’t perform the requested M= easurement Task. So the Control Protocol needs to allow the MA to reply wit= h an error code. It has also been suggested that the Controller should be a= ble to ask the MA to send a list of all the Measurement Methods that it is = capable of, in case ‘something goes wrong’ and the Controller f= orgets what the MA can do. Comment: this idea hasn’t had much discuss= ion yet, but appears in the Information Model i-d

 

Thoughts? =

Thanks

phil

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411E3AEMV67UKRDdoma_-- From paitken@cisco.com Thu Sep 5 04:16:06 2013 Return-Path: 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 40E1A21E80ED for ; Thu, 5 Sep 2013 04:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0iY1PgPUxLdw for ; Thu, 5 Sep 2013 04:16:01 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9879C21E80BA for ; Thu, 5 Sep 2013 04:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10676; q=dns/txt; s=iport; t=1378379760; x=1379589360; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=BRwae08h6MZMVv0844WdP/s+AoraGzIqdPThHjel5Q8=; b=iQtFrKxg0OQ98rm/BmmwR2eUsN5+jvsbCNPqMDTEIU1HPIFFblV/HBrq D2Z9SGhaMioa2nwuR4x8raQKIZc9VBa6GA91ZmQCcoNlCaWZCCW4MC/Xy v1i3+6O0PWUhcinVyJsiHhfPutxSPrIhom0ipHpESqeD4cyc3nlo1kChh E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAGFmKFKQ/khR/2dsb2JhbABbgkNENYlWuEGBKBZ0giQBAQEDAQEBASpBCgEFCwshFg8JAwIBAgEVMBMBBQIBAYd4Bgy6P49gB4QdA4FRliSBL4R9izqDIQ X-IronPort-AV: E=Sophos;i="4.90,846,1371081600"; d="scan'208,217";a="17299936" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 05 Sep 2013 11:15:52 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r85BFn4k029956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Sep 2013 11:15:50 GMT Received: from [10.61.220.173] ([10.61.220.173]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r85BFmc3002609; Thu, 5 Sep 2013 12:15:49 +0100 (BST) Message-ID: <522867E5.3070205@cisco.com> Date: Thu, 05 Sep 2013 12:15:49 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: philip.eardley@bt.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010600070803050406080400" Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 11:16:06 -0000 This is a multi-part message in MIME format. --------------010600070803050406080400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phil, A controller can't forget what an MA can do unless / untll it first knows... so presumably there's a discovery phase where a (new) controller becomes aware of which MAs are within its control, and what the capabilities of each MA are. This has to be a dynamic process so new MAs can appear (and disappear) at any time. Whether the controller discovers MAs, or the MAs announce themselves to the controller depends on the protocol, firewalls, etc. See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8 After this there are a couple of failure scenarios: * Immediate: the controller requests an MA perform a test; the MA knows it's not capable of performing that test (eg due to a conflict or lack of resources). The MA can immediately indicate an error code to the controller. The controller could request a different test or choose a different MA. * Future: the controller requests an MA perform a test in the future (eg, at midnight), or a repeating test (eg, hourly). The MA accepts the test, indicating OK to the controller. Later the MA later discovers that it's not capable of performing the test. Depending on the control protocol, there may or may not be a connection between the MA and the controller. So the MA may have to indicate an error to the collector - especially if it wants to report partial results for an incomplete repeating test. If the MA indicates the error to the collector, does the collector need to tell the controller that the test didn't happen, or only partially happened? Aamer and I supposed so, which is why we added the controller / collector feedback loop. OTOH, if the controller doesn't need to know that the test(s) didn't happen, then why do we need error codes at all? The controller tells an MA to perform the test, and either it does or doesn't... it doesn't make sense, right? P. > Another issue: > > There is no negotiation between the MA and Controller - the Controller > simply sends the Instruction to the MA, with the details of the > Measurement Tasks to perform. > > In general we expect that the measurement system understands the > capabilities of its MAs (probably there are only one or a few classes > of MA), so negotiation about the MA's capabilities would have little > benefit. It would also add complexity to the MA, Controller and > Control Protocol. > > It is possible that the MA can't perform the requested Measurement > Task. So the Control Protocol needs to allow the MA to reply with an > error code. It has also been suggested that the Controller should be > able to ask the MA to send a list of all the Measurement Methods that > it is capable of, in case 'something goes wrong' and the Controller > forgets what the MA can do. Comment: this idea hasn't had much > discussion yet, but appears in the Information Model i-d > > Thoughts? > > Thanks > > phil > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --------------010600070803050406080400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Phil,

A controller can't forget what an MA can do unless / untll it first knows... so presumably there's a discovery phase where a (new) controller becomes aware of which MAs are within its control, and what the capabilities of each MA are. This has to be a dynamic process so new MAs can appear (and disappear) at any time. Whether the controller discovers MAs, or the MAs announce themselves to the controller depends on the protocol, firewalls, etc.

See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8


After this there are a couple of failure scenarios:

* Immediate: the controller requests an MA perform a test; the MA knows it's not capable of performing that test (eg due to a conflict or lack of resources). The MA can immediately indicate an error code to the controller. The controller could request a different test or choose a different MA.

* Future: the controller requests an MA perform a test in the future (eg, at midnight), or a repeating test (eg, hourly). The MA accepts the test, indicating OK to the controller. Later the MA later discovers that it's not capable of performing the test. Depending on the control protocol, there may or may not be a connection between the MA and the controller. So the MA may have to indicate an error to the collector - especially if it wants to report partial results for an incomplete repeating test.

If the MA indicates the error to the collector, does the collector need to tell the controller that the test didn't happen, or only partially happened? Aamer and I supposed so, which is why we added the controller / collector feedback loop. OTOH, if the controller doesn't need to know that the test(s) didn't happen, then why do we need error codes at all? The controller tells an MA to perform the test, and either it does or doesn't... it doesn't make sense, right?

P.


Another issue:

There is no negotiation between the MA and Controller - the Controller simply sends the Instruction to the MA, with the details of the Measurement Tasks to perform.

In general we expect that the measurement system understands the capabilities of its MAs (probably there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. It would also add complexity to the MA, Controller and Control Protocol.

 

It is possible that the MA can’t perform the requested Measurement Task. So the Control Protocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to send a list of all the Measurement Methods that it is capable of, in case ‘something goes wrong’ and the Controller forgets what the MA can do. Comment: this idea hasn’t had much discussion yet, but appears in the Information Model i-d

 

Thoughts?

Thanks

phil



_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap

--------------010600070803050406080400-- From trammell@tik.ee.ethz.ch Thu Sep 5 04:56:39 2013 Return-Path: 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 4086721E80F8 for ; Thu, 5 Sep 2013 04:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 WtdL5ANSx967 for ; Thu, 5 Sep 2013 04:56:33 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 05BD511E8125 for ; Thu, 5 Sep 2013 04:56:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 66211D9303; Thu, 5 Sep 2013 13:56:31 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2duMk7xCEfFG; Thu, 5 Sep 2013 13:56:31 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 37ABAD9300; Thu, 5 Sep 2013 13:56:31 +0200 (MEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: Date: Thu, 5 Sep 2013 13:56:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> References: To: X-Mailer: Apple Mail (2.1508) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 11:56:39 -0000 Hi, Phil, all, Some points on this inline... On 5 Sep 2013, at 12:13 , wrote: > Another issue: > There is no negotiation between the MA and Controller - the Controller = simply sends the Instruction to the MA, with the details of the = Measurement Tasks to perform. > In general we expect that the measurement system understands the = capabilities of its MAs (probably there are only one or a few classes of = MA), so negotiation about the MA=92s capabilities would have little = benefit. It would also add complexity to the MA, Controller and Control = Protocol. First, there's a separation between negotiation and capabilities = advertisement. The former allows MAs and Controllers to iteratively = agree on what the MA can and will do with respect to a given Task; the = latter provides a method for the MA to tell the Controller what it might = be willing to do at some point in the future.=20 Negotiation, as I see it, is significantly more complicated that = advertisement; in the latter case, a Controller can simply select to use = the subset of MAs -- the negotiation algorithm is local to the = Controller in this case, and doesn't touch the protocol at all. I'm somewhat skeptical that a system relying on static capabilities -- = i.e. with neither negotiation nor capabilities advertisement -- will = ever be deployable and manageable. It presumes that all MAs are the = same, and that their capabilities never change over their lifetimes; = that the set of basic capabilities presumed to be supported by all/most = MAs will never change; it also presumes that no MA can support any = additional measurement services beyond the base profile, which makes it = difficult for different MA vendors to differentiate their = implementations. I know that _discovery_ of MAs is explicitly out of scope to allow = integration with (access network technology bound) device management = protocols, but it seems we really need some way to bind what an MA can = do to its identification. > It is possible that the MA can=92t perform the requested Measurement = Task. So the Control Protocol needs to allow the MA to reply with an = error code. This is more useful in use cases where the controller cares about the = results from a specific MA. In an environment with thousands of MAs with = varying connectivity, requiring a back channel for errors (and/or = requiring the Controller to actually _do_ something about this error) = seems like a lot of overhead for zero actionable insight.=20 > It has also been suggested that the Controller should be able to ask = the MA to send a list of all the Measurement Methods that it is capable = of, in case =91something goes wrong=92 and the Controller forgets what = the MA can do. This would be a nice way to implement capability advertisement without = linking it to discovery, actually. Downside is you end up with something = that looks like negotiation on association: discover - associate - = capability query - capability advertisement response - now we can = measure something. Cheers, Brian From dengguangqing@cnnic.cn Thu Sep 5 05:08:50 2013 Return-Path: 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 72A5521F9D02 for ; Thu, 5 Sep 2013 05:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 YBmZvGeY0TUN for ; Thu, 5 Sep 2013 05:08:46 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 73AA421F9D33 for ; Thu, 5 Sep 2013 05:08:44 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO dgq-pc) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 05 Sep 2013 20:08:29 +0800 Date: Thu, 5 Sep 2013 20:08:30 +0800 From: "Guangqing Deng" To: "lmap@ietf.org" References: , <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 2, 36[cn] Mime-Version: 1.0 Message-ID: <201309052008294922025@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart618440622287_=----" Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 12:08:50 -0000 This is a multi-part message in MIME format. ------=_001_NextPart618440622287_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbCwgSSB0aGluayB0aGUgcmVxdWlyZW1lbnRzIG9mIG5lZ290aWF0aW9uIHByb3RvY29s cyBiZXR3ZWVuIE1BIGFuZCBjb250cm9sbGVyIGRvIGV4aXQgYW5kIHdpbGwgY29udGludW91c2x5 IGJlIHByb3Bvc2VkLCBzaW5jZSBtb3JlIHN1Y2ggcHJvdG9jb2xzIG1lYW4gbW9yZQ0KY29udmVu aWVuY2UgZm9yIHBlcmZvcm1pbmcgbWVhc3VyZW1lbnRzLiBIb3dldmVyLCBtb3JlIHByb3RvY29s cyBhbHNvIG1lYW4gdGhhdCBNQXMgaGF2ZSB0byBhcHBseSBtb3JlIHJlc291cmNlcyAobGlrZSBD UFUgYW5kIGJhbmR3aWR0aCkgb24gbWVhc3VyZW1lbnRzLA0Kd2hpY2ggaXMgT0sgZm9yIGZpeGVk IE1BcyBsaWtlIGRlc2t0b3BzLCBsYXB0b3BzLCBhbmQgb3RoZXIgc3VjaCBraW5kcyBvZiBNQXMu IEJ1dCBtb2JpbGUgTUFzIChzdWNoIGFzIHNtYXJ0IHBob25lcykgbWF5IGJlIHNlbnNpdGl2ZSBh Ym91dCB0aGF0IChuYW1lbHkgdGhlIA0KY29tcGxleGl0eSBvZiBwcm90b2NvbHMpLiBTbyBtYXli ZSBpdCBpcyBuZWNlc3NhcnkgdG8gZGl2aWRlIHRoZXNlIHJlcXVpcmVtZW50cyBpbnRvIHR3byBr aW5kczogYmFzaWMgYW5kIGV4dGVuZGVkIG9uZXMuIFRoZSBiYXNpYyBvbmVzIGFyZSBzdWl0YWJs ZSBmb3IgYm90aCANCm1vYmlsZSBhbmQgZml4ZWQgTUFzLCBhbmQgdGhlIGV4dGVuZGVkIG9uZXMg YXJlIG9ubHkgZm9yIHRob3NlIG90aGVyIHRoYW4gbW9iaWxlIE1Bcy4gSW4gYSB3b3JkLCB0aGUg cHJvdG9jb2wgY29tcGxleGl0eSBzaG91bGQgYmUgZGVsaWJlcmF0ZWx5IGNvbnRyb2xsZWQuDQoN Cg0KDQoNCkd1YW5ncWluZyBEZW5nDQpjbm5pYyANCg0KRnJvbTogQnJpYW4gVHJhbW1lbGwNCkRh dGU6IDIwMTMtMDktMDUgMTk6NTYNClRvOiBwaGlsaXAuZWFyZGxleUBidC5jb20NCkNDOiBsbWFw DQpTdWJqZWN0OiBSZTogW2xtYXBdIExNQVAgRnJhbWV3b3JrIGlzc3VlICMzIE5vIG5lZ290aWF0 aW9uIGJldHdlZW4gTUEgYW5kIENvbnRyb2xsZXINCkhpLCBQaGlsLCBhbGwsDQoNClNvbWUgcG9p bnRzIG9uIHRoaXMgaW5saW5lLi4uDQoNCk9uIDUgU2VwIDIwMTMsIGF0IDEyOjEzICwgPHBoaWxp cC5lYXJkbGV5QGJ0LmNvbT4gd3JvdGU6DQoNCj4gQW5vdGhlciBpc3N1ZToNCj4gVGhlcmUgaXMg bm8gbmVnb3RpYXRpb24gYmV0d2VlbiB0aGUgTUEgYW5kIENvbnRyb2xsZXIgLSB0aGUgQ29udHJv bGxlciBzaW1wbHkgc2VuZHMgdGhlIEluc3RydWN0aW9uIHRvIHRoZSBNQSwgd2l0aCB0aGUgZGV0 YWlscyBvZiB0aGUgTWVhc3VyZW1lbnQgVGFza3MgdG8gcGVyZm9ybS4NCj4gSW4gZ2VuZXJhbCB3 ZSBleHBlY3QgdGhhdCB0aGUgbWVhc3VyZW1lbnQgc3lzdGVtIHVuZGVyc3RhbmRzIHRoZSBjYXBh YmlsaXRpZXMgb2YgaXRzIE1BcyAocHJvYmFibHkgdGhlcmUgYXJlIG9ubHkgb25lIG9yIGEgZmV3 IGNsYXNzZXMgb2YgTUEpLCBzbyBuZWdvdGlhdGlvbiBhYm91dCB0aGUgTUHigJlzIGNhcGFiaWxp dGllcyB3b3VsZCBoYXZlIGxpdHRsZSBiZW5lZml0LiBJdCB3b3VsZCBhbHNvIGFkZCBjb21wbGV4 aXR5IHRvIHRoZSBNQSwgQ29udHJvbGxlciBhbmQgQ29udHJvbCBQcm90b2NvbC4NCg0KRmlyc3Qs IHRoZXJlJ3MgYSBzZXBhcmF0aW9uIGJldHdlZW4gbmVnb3RpYXRpb24gYW5kIGNhcGFiaWxpdGll cyBhZHZlcnRpc2VtZW50LiBUaGUgZm9ybWVyIGFsbG93cyBNQXMgYW5kIENvbnRyb2xsZXJzIHRv IGl0ZXJhdGl2ZWx5IGFncmVlIG9uIHdoYXQgdGhlIE1BIGNhbiBhbmQgd2lsbCBkbyB3aXRoIHJl c3BlY3QgdG8gYSBnaXZlbiBUYXNrOyB0aGUgbGF0dGVyIHByb3ZpZGVzIGEgbWV0aG9kIGZvciB0 aGUgTUEgdG8gdGVsbCB0aGUgQ29udHJvbGxlciB3aGF0IGl0IG1pZ2h0IGJlIHdpbGxpbmcgdG8g ZG8gYXQgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlLiANCg0KTmVnb3RpYXRpb24sIGFzIEkgc2Vl IGl0LCBpcyBzaWduaWZpY2FudGx5IG1vcmUgY29tcGxpY2F0ZWQgdGhhdCBhZHZlcnRpc2VtZW50 OyBpbiB0aGUgbGF0dGVyIGNhc2UsIGEgQ29udHJvbGxlciBjYW4gc2ltcGx5IHNlbGVjdCB0byB1 c2UgdGhlIHN1YnNldCBvZiBNQXMgLS0gdGhlIG5lZ290aWF0aW9uIGFsZ29yaXRobSBpcyBsb2Nh bCB0byB0aGUgQ29udHJvbGxlciBpbiB0aGlzIGNhc2UsIGFuZCBkb2Vzbid0IHRvdWNoIHRoZSBw cm90b2NvbCBhdCBhbGwuDQoNCkknbSBzb21ld2hhdCBza2VwdGljYWwgdGhhdCBhIHN5c3RlbSBy ZWx5aW5nIG9uIHN0YXRpYyBjYXBhYmlsaXRpZXMgLS0gaS5lLiB3aXRoIG5laXRoZXIgbmVnb3Rp YXRpb24gbm9yIGNhcGFiaWxpdGllcyBhZHZlcnRpc2VtZW50IC0tIHdpbGwgZXZlciBiZSBkZXBs b3lhYmxlIGFuZCBtYW5hZ2VhYmxlLiBJdCBwcmVzdW1lcyB0aGF0IGFsbCBNQXMgYXJlIHRoZSBz YW1lLCBhbmQgdGhhdCB0aGVpciBjYXBhYmlsaXRpZXMgbmV2ZXIgY2hhbmdlIG92ZXIgdGhlaXIg bGlmZXRpbWVzOyB0aGF0IHRoZSBzZXQgb2YgYmFzaWMgY2FwYWJpbGl0aWVzIHByZXN1bWVkIHRv IGJlIHN1cHBvcnRlZCBieSBhbGwvbW9zdCBNQXMgd2lsbCBuZXZlciBjaGFuZ2U7IGl0IGFsc28g cHJlc3VtZXMgdGhhdCBubyBNQSBjYW4gc3VwcG9ydCBhbnkgYWRkaXRpb25hbCBtZWFzdXJlbWVu dCBzZXJ2aWNlcyBiZXlvbmQgdGhlIGJhc2UgcHJvZmlsZSwgd2hpY2ggbWFrZXMgaXQgZGlmZmlj dWx0IGZvciBkaWZmZXJlbnQgTUEgdmVuZG9ycyB0byBkaWZmZXJlbnRpYXRlIHRoZWlyIGltcGxl bWVudGF0aW9ucy4NCg0KSSBrbm93IHRoYXQgX2Rpc2NvdmVyeV8gb2YgTUFzIGlzIGV4cGxpY2l0 bHkgb3V0IG9mIHNjb3BlIHRvIGFsbG93IGludGVncmF0aW9uIHdpdGggKGFjY2VzcyBuZXR3b3Jr IHRlY2hub2xvZ3kgYm91bmQpIGRldmljZSBtYW5hZ2VtZW50IHByb3RvY29scywgYnV0IGl0IHNl ZW1zIHdlIHJlYWxseSBuZWVkIHNvbWUgd2F5IHRvIGJpbmQgd2hhdCBhbiBNQSBjYW4gZG8gdG8g aXRzIGlkZW50aWZpY2F0aW9uLg0KDQo+IEl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIE1BIGNhbuKA mXQgcGVyZm9ybSB0aGUgcmVxdWVzdGVkIE1lYXN1cmVtZW50IFRhc2suIFNvIHRoZSBDb250cm9s IFByb3RvY29sIG5lZWRzIHRvIGFsbG93IHRoZSBNQSB0byByZXBseSB3aXRoIGFuIGVycm9yIGNv ZGUuDQoNClRoaXMgaXMgbW9yZSB1c2VmdWwgaW4gdXNlIGNhc2VzIHdoZXJlIHRoZSBjb250cm9s bGVyIGNhcmVzIGFib3V0IHRoZSByZXN1bHRzIGZyb20gYSBzcGVjaWZpYyBNQS4gSW4gYW4gZW52 aXJvbm1lbnQgd2l0aCB0aG91c2FuZHMgb2YgTUFzIHdpdGggdmFyeWluZyBjb25uZWN0aXZpdHks IHJlcXVpcmluZyBhIGJhY2sgY2hhbm5lbCBmb3IgZXJyb3JzIChhbmQvb3IgcmVxdWlyaW5nIHRo ZSBDb250cm9sbGVyIHRvIGFjdHVhbGx5IF9kb18gc29tZXRoaW5nIGFib3V0IHRoaXMgZXJyb3Ip IHNlZW1zIGxpa2UgYSBsb3Qgb2Ygb3ZlcmhlYWQgZm9yIHplcm8gYWN0aW9uYWJsZSBpbnNpZ2h0 LiANCg0KPiBJdCBoYXMgYWxzbyBiZWVuIHN1Z2dlc3RlZCB0aGF0IHRoZSBDb250cm9sbGVyIHNo b3VsZCBiZSBhYmxlIHRvIGFzayB0aGUgTUEgdG8gc2VuZCBhIGxpc3Qgb2YgYWxsIHRoZSBNZWFz dXJlbWVudCBNZXRob2RzIHRoYXQgaXQgaXMgY2FwYWJsZSBvZiwgaW4gY2FzZSDigJhzb21ldGhp bmcgZ29lcyB3cm9uZ+KAmSBhbmQgdGhlIENvbnRyb2xsZXIgZm9yZ2V0cyB3aGF0IHRoZSBNQSBj YW4gZG8uDQoNClRoaXMgd291bGQgYmUgYSBuaWNlIHdheSB0byBpbXBsZW1lbnQgY2FwYWJpbGl0 eSBhZHZlcnRpc2VtZW50IHdpdGhvdXQgbGlua2luZyBpdCB0byBkaXNjb3ZlcnksIGFjdHVhbGx5 LiBEb3duc2lkZSBpcyB5b3UgZW5kIHVwIHdpdGggc29tZXRoaW5nIHRoYXQgbG9va3MgbGlrZSBu ZWdvdGlhdGlvbiBvbiBhc3NvY2lhdGlvbjogZGlzY292ZXIgLSBhc3NvY2lhdGUgLSBjYXBhYmls aXR5IHF1ZXJ5IC0gY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50IHJlc3BvbnNlIC0gbm93IHdlIGNh biBtZWFzdXJlIHNvbWV0aGluZy4NCg0KQ2hlZXJzLA0KDQpCcmlhbg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbG1hcCBtYWlsaW5nIGxpc3QNCmxt YXBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcA== ------=_001_NextPart618440622287_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF

Hi, all, I think the requirements of negotiation=20 protocols between MA and controller do exit and will continuously be propo= sed,=20 since more such protocols mean more

convenience for performing measurements. However,= more=20 protocols also mean that MAs have to apply more resources (like CPU and=20 bandwidth) on measurements,

which is OK for fixed MAs like desktops, laptops,= and=20 other such kinds of MAs. But mobile MAs (such as smart phones) may be sens= itive=20 about that (namely the

complexity of protocols). So maybe it is necessar= y to=20 divide these requirements into two kinds: basic and extended ones. The bas= ic=20 ones are suitable for both

mobile and fixed MAs, and the extended ones are o= nly for=20 those other than mobile MAs. In a word, the protocol complexity should be=20 deliberately controlled.

 
Guangqing=20 Deng
cnnic 
 
Date: 2013-09-05 19:56
To: philip.eardley@bt.com
CC: lmap
Subject: Re: [lmap] LMAP Framework issue #3 No negotiatio= n=20 between MA and Controller
Hi, Phil, all,
 
Some points on this inline...
 
On 5 Sep 2013, at 12:13 , <philip.eardley@bt.com> wrote:
 
> Another issue:
> There is no negotiation between the MA and Controller - the Cont= roller=20 simply sends the Instruction to the MA, with the details of the Measuremen= t=20 Tasks to perform.
> In general we expect that the measurement system understands the= =20 capabilities of its MAs (probably there are only one or a few classes of M= A), so=20 negotiation about the MA=E2=80=99s capabilities would have little benefit.= It would also=20 add complexity to the MA, Controller and Control Protocol.
 
First, there's a separation between negotiation and capabilities=20 advertisement. The former allows MAs and Controllers to iteratively agree = on=20 what the MA can and will do with respect to a given Task; the latter provi= des a=20 method for the MA to tell the Controller what it might be willing to do at= some=20 point in the future.
 
Negotiation, as I see it, is significantly more complicated that=20 advertisement; in the latter case, a Controller can simply select to use t= he=20 subset of MAs -- the negotiation algorithm is local to the Controller in t= his=20 case, and doesn't touch the protocol at all.
 
I'm somewhat skeptical that a system relying on static capabilities -= - i.e.=20 with neither negotiation nor capabilities advertisement -- will ever be=20 deployable and manageable. It presumes that all MAs are the same, and that= their=20 capabilities never change over their lifetimes; that the set of basic=20 capabilities presumed to be supported by all/most MAs will never change; i= t also=20 presumes that no MA can support any additional measurement services beyond= the=20 base profile, which makes it difficult for different MA vendors to differe= ntiate=20 their implementations.
 
I know that _discovery_ of MAs is explicitly out of scope to allow=20 integration with (access network technology bound) device management proto= cols,=20 but it seems we really need some way to bind what an MA can do to its=20 identification.
 
> It is possible that the MA can=E2=80=99t perform the requested M= easurement=20 Task. So the Control Protocol needs to allow the MA to reply with an error= =20 code.
 
This is more useful in use cases where the controller cares about the= =20 results from a specific MA. In an environment with thousands of MAs with v= arying=20 connectivity, requiring a back channel for errors (and/or requiring the=20 Controller to actually _do_ something about this error) seems like a lot o= f=20 overhead for zero actionable insight.
 
> It has also been suggested that the Controller should be able to= ask=20 the MA to send a list of all the Measurement Methods that it is capable of= , in=20 case =E2=80=98something goes wrong=E2=80=99 and the Controller forgets wha= t the MA can do.
 
This would be a nice way to implement capability advertisement withou= t=20 linking it to discovery, actually. Downside is you end up with something t= hat=20 looks like negotiation on association: discover - associate - capability q= uery -=20 capability advertisement response - now we can measure something.
 
Cheers,
 
Brian
 
_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap
------=_001_NextPart618440622287_=------ From philip.eardley@bt.com Thu Sep 5 05:30:52 2013 Return-Path: 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 C3E1511E8192 for ; Thu, 5 Sep 2013 05:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 K8Vy8qjC+pjl for ; Thu, 5 Sep 2013 05:30:47 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4A311E818B for ; Thu, 5 Sep 2013 05:30:46 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 5 Sep 2013 13:30:43 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Thu, 5 Sep 2013 13:30:43 +0100 From: To: Date: Thu, 5 Sep 2013 13:30:42 +0100 Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: Ac6qLvdGmzWSP0NyQr6Nnzj2HS+EUgAAocww Message-ID: References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> In-Reply-To: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 12:30:52 -0000 > Negotiation, as I see it, is significantly more complicated that > advertisement; Agree. > I'm somewhat skeptical that a system relying on static capabilities -- > i.e. with neither negotiation nor capabilities advertisement -- will > ever be deployable and manageable. My assumption (which I should have stated!): the measurement system needs to know the capabilities of its MAs. it will d= o this as part of deployment and bootstrapping. If the measurement system u= pdates the MA's capabilities, eg with some new Measurement Methods, then th= e measurement system (& Controller) should know about it. The WG is supposed to think about the bootstrapping process but doesn't def= ine a detailed bootstrap protocol (I think the latter is out of scope, on t= he basis that's it depends on the access/device type, eg use TR-069 for BBF= devices etc).=20 I think so far we (or at least I) have been quite vague about what this mea= ns. We could do with some more detailed work, perhaps it would reveal that = some useful things don't depend on the access/device type, so could be good= for lmap wg to define? > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: 05 September 2013 12:57 > To: Eardley,PL,Philip,TUB8 R > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA > and Controller >=20 > Hi, Phil, all, >=20 > Some points on this inline... >=20 > On 5 Sep 2013, at 12:13 , wrote: >=20 > > Another issue: > > There is no negotiation between the MA and Controller - the > Controller simply sends the Instruction to the MA, with the details of > the Measurement Tasks to perform. > > In general we expect that the measurement system understands the > capabilities of its MAs (probably there are only one or a few classes > of MA), so negotiation about the MA's capabilities would have little > benefit. It would also add complexity to the MA, Controller and Control > Protocol. >=20 > First, there's a separation between negotiation and capabilities > advertisement. The former allows MAs and Controllers to iteratively > agree on what the MA can and will do with respect to a given Task; the > latter provides a method for the MA to tell the Controller what it > might be willing to do at some point in the future. >=20 > Negotiation, as I see it, is significantly more complicated that > advertisement; in the latter case, a Controller can simply select to > use the subset of MAs -- the negotiation algorithm is local to the > Controller in this case, and doesn't touch the protocol at all. >=20 > I'm somewhat skeptical that a system relying on static capabilities -- > i.e. with neither negotiation nor capabilities advertisement -- will > ever be deployable and manageable. It presumes that all MAs are the > same, and that their capabilities never change over their lifetimes; > that the set of basic capabilities presumed to be supported by all/most > MAs will never change; it also presumes that no MA can support any > additional measurement services beyond the base profile, which makes it > difficult for different MA vendors to differentiate their > implementations. >=20 > I know that _discovery_ of MAs is explicitly out of scope to allow > integration with (access network technology bound) device management > protocols, but it seems we really need some way to bind what an MA can > do to its identification. >=20 > > It is possible that the MA can't perform the requested Measurement > Task. So the Control Protocol needs to allow the MA to reply with an > error code. >=20 > This is more useful in use cases where the controller cares about the > results from a specific MA. In an environment with thousands of MAs > with varying connectivity, requiring a back channel for errors (and/or > requiring the Controller to actually _do_ something about this error) > seems like a lot of overhead for zero actionable insight. >=20 > > It has also been suggested that the Controller should be able to ask > the MA to send a list of all the Measurement Methods that it is capable > of, in case 'something goes wrong' and the Controller forgets what the > MA can do. >=20 > This would be a nice way to implement capability advertisement without > linking it to discovery, actually. Downside is you end up with > something that looks like negotiation on association: discover - > associate - capability query - capability advertisement response - now > we can measure something. >=20 > Cheers, >=20 > Brian From philip.eardley@bt.com Thu Sep 5 05:55:55 2013 Return-Path: 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 5FB6F21E80CA for ; Thu, 5 Sep 2013 05:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.123 X-Spam-Level: X-Spam-Status: No, score=-103.123 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 iVwY+JR-qxLN for ; Thu, 5 Sep 2013 05:55:50 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id D24F221E80FF for ; Thu, 5 Sep 2013 05:55:47 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 5 Sep 2013 13:55:45 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 5 Sep 2013 13:55:45 +0100 From: To: Date: Thu, 5 Sep 2013 13:55:44 +0100 Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: Ac6qKUk7LzCpoquSQ+muZMCeV4z3fgACnTlQ Message-ID: References: <522867E5.3070205@cisco.com> In-Reply-To: <522867E5.3070205@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411EACEMV67UKRDdoma_" MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 12:55:55 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411EACEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think lmap should define a dynamic MA discovery protocol On your "Future" bullet - << Later the MA later discovers that it's not cap= able of performing the test>> I was assuming that the MA understands what Measurement Methods it can do, = so it should know at the time when it gets the Instruction whether it can d= o the test or not. So I'm not that worried about the MA later realising it = can't. My assumption here - the operator of the measurement system checks in the l= ab what Methods can run on which of its types of MAs - it allows some margi= n for error - it definitely doesn't try and operate Methods which will run = ok sometimes and not at other times (when the device containing the MA is "= busy"). If the Result isn't collected or is suspected of being wrong for some reaso= n, then it's marked when the Results are reported. I agree in some circumst= ances the measurement system may want to tell the Controller (the feedback = loop out of scope of lmap to define) Thanks Phil From: Paul Aitken [mailto:paitken@cisco.com] Sent: 05 September 2013 12:16 To: Eardley,PL,Philip,TUB8 R Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and C= ontroller Phil, A controller can't forget what an MA can do unless / untll it first knows..= . so presumably there's a discovery phase where a (new) controller becomes = aware of which MAs are within its control, and what the capabilities of eac= h MA are. This has to be a dynamic process so new MAs can appear (and disap= pear) at any time. Whether the controller discovers MAs, or the MAs announc= e themselves to the controller depends on the protocol, firewalls, etc. See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8 After this there are a couple of failure scenarios: * Immediate: the controller requests an MA perform a test; the MA knows it'= s not capable of performing that test (eg due to a conflict or lack of reso= urces). The MA can immediately indicate an error code to the controller. Th= e controller could request a different test or choose a different MA. * Future: the controller requests an MA perform a test in the future (eg, a= t midnight), or a repeating test (eg, hourly). The MA accepts the test, ind= icating OK to the controller. Later the MA later discovers that it's not ca= pable of performing the test. Depending on the control protocol, there may = or may not be a connection between the MA and the controller. So the MA may= have to indicate an error to the collector - especially if it wants to rep= ort partial results for an incomplete repeating test. If the MA indicates the error to the collector, does the collector need to = tell the controller that the test didn't happen, or only partially happened= ? Aamer and I supposed so, which is why we added the controller / collector= feedback loop. OTOH, if the controller doesn't need to know that the test(= s) didn't happen, then why do we need error codes at all? The controller te= lls an MA to perform the test, and either it does or doesn't... it doesn't = make sense, right? P. Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411EACEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I don’t think lmap should define a dynamic MA discovery protocol

 

On your “Future” bullet – << Later the MA later discovers that it's not capable of performing the tes= t>>

I was assuming that= the MA understands what Measurement Methods it can do, so it should know a= t the time when it gets the Instruction whether it can do the test or not. = So I’m not that worried about the MA later realising it can’t. =

 

My assumption here – the operator of the measure= ment system checks in the lab what Methods can run on which of its types of= MAs – it allows some margin for error – it definitely doesn= 217;t try and operate Methods which will run ok sometimes and not at other = times (when the device containing the MA is “busy”).=

 

If the Result isn’t collected or is suspected of being wron= g for some reason, then it’s marked when the Results are reported. I = agree in some circumstances the measurement system may want to tell the Con= troller (the feedback loop out of scope of lmap to define)

 

Thanks

Phil

 

From: Paul Ait= ken [mailto:paitken@cisco.com]
Sent: 05 September 2013 12:16
= To: Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org
Subje= ct: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Co= ntroller

 <= /o:p>

Phil,
=
A controller can't forget what an MA can do unless / untll it first kno= ws... so presumably there's a discovery phase where a (new) controller beco= mes aware of which MAs are within its control, and what the capabilities of= each MA are. This has to be a dynamic process so new MAs can appear (and d= isappear) at any time. Whether the controller discovers MAs, or the MAs ann= ounce themselves to the controller depends on the protocol, firewalls, etc.=

See http://tools.ietf.org/html/draft-akhter-lmap-framework-0= 0#section-3.8


After this there are a couple of failure scena= rios:

* Immediate: the controller requests an MA perform a test; the= MA knows it's not capable of performing that test (eg due to a conflict or= lack of resources). The MA can immediately indicate an error code to the c= ontroller. The controller could request a different test or choose a differ= ent MA.

* Future: the controller requests an MA perform a test in th= e future (eg, at midnight), or a repeating test (eg, hourly). The MA accept= s the test, indicating OK to the controller. Later the MA later discovers t= hat it's not capable of performing the test. Depending on the control proto= col, there may or may not be a connection between the MA and the controller= . So the MA may have to indicate an error to the collector - especially if = it wants to report partial results for an incomplete repeating test.
If the MA indicates the error to the collector, does the collector need to= tell the controller that the test didn't happen, or only partially happene= d? Aamer and I supposed so, which is why we added the controller / collecto= r feedback loop. OTOH, if the controller doesn't need to know that the test= (s) didn't happen, then why do we need error codes at all? The controller t= ells an MA to perform the test, and either it does or doesn't... it doesn't= make sense, right?

P.

Another= issue:

There is no negotiati= on between the MA and Controller - the Controller simply sends the Instruct= ion to the MA, with the details of the Measurement Tasks to perform.

In general we expect that the meas= urement system understands the capabilities of its MAs (probably there are = only one or a few classes of MA), so negotiation about the MA’s capab= ilities would have little benefit. It would also add complexity to the MA, = Controller and Control Protocol.

 

It is possible th= at the MA can’t perform the requested Measurement Task. So the Contro= l Protocol needs to allow the MA to reply with an error code. It has also b= een suggested that the Controller should be able to ask the MA to send a li= st of all the Measurement Methods that it is capable of, in case ‘som= ething goes wrong’ and the Controller forgets what the MA can do. Com= ment: this idea hasn’t had much discussion yet, but appears in the In= formation Model i-d

 <= /span>

Thoughts? <= /p>

Thanks

phil




___________________________________=
____________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mail=
man/listinfo/lmap

 

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411EACEMV67UKRDdoma_-- From rolf.winter@hs-augsburg.de Thu Sep 5 05:56:16 2013 Return-Path: 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 41F5421E8105 for ; Thu, 5 Sep 2013 05:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6] 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 G9GeGk5npwsP for ; Thu, 5 Sep 2013 05:56:15 -0700 (PDT) Received: from fly-neu.RZ.HS-Augsburg.DE (fly-neu.RZ.HS-Augsburg.DE [IPv6:2001:638:102:2::217:48]) by ietfa.amsl.com (Postfix) with ESMTP id 5050321E810A for ; Thu, 5 Sep 2013 05:56:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by fly-neu.RZ.HS-Augsburg.DE (Postfix) with ESMTP id 9AA931D624F for ; Thu, 5 Sep 2013 14:56:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hs-augsburg.de Received: from fly-neu.RZ.HS-Augsburg.DE ([127.0.0.1]) by localhost (fly-neu.rz.hs-augsburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6TToo2mQqPaD for ; Thu, 5 Sep 2013 14:56:07 +0200 (CEST) Received: from Rolfs-MacBook-Pro.local (unknown [141.82.51.130]) by fly-neu.RZ.HS-Augsburg.DE (Postfix) with ESMTPSA id D5F7E1D624C for ; Thu, 5 Sep 2013 14:56:07 +0200 (CEST) Message-ID: <52287F67.3010401@hs-augsburg.de> Date: Thu, 05 Sep 2013 14:56:07 +0200 From: Rolf Winter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: lmap@ietf.org References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 12:56:16 -0000 Hi, if the MA is e.g. my home gateway, I can potentially upgrade its firmware anytime I want (something I can do right now with my HGW at home) which could add or remove capabilities. What if you have a market where the regulator allows a customer to use a HGW of his/her liking which does not guarantee a standard set of capabilities. What if your HGW allows a user to enable/disable measurement features. Then during the lifetime of the MA, capabilities can change after bootstrapping. If this is important information for an LMAP controller, I am not entirely sure you want to outsource it to a third party protocol. Advertising capabilities seems not a very heavyweight and complex operation to me. Even in error reports you could advertise the currently supported capabilities and not just have a code that says "no can do". Both seem useful, i.e. error on a non-supported measurement request and a structured way of querying that information. The latter would then be part of the bootstrapping process I guess. Best, Rolf On 9/5/13 2:30 PM, philip.eardley@bt.com wrote: >> Negotiation, as I see it, is significantly more complicated that >> advertisement; > Agree. > >> I'm somewhat skeptical that a system relying on static capabilities -- >> i.e. with neither negotiation nor capabilities advertisement -- will >> ever be deployable and manageable. > > My assumption (which I should have stated!): > the measurement system needs to know the capabilities of its MAs. it will do this as part of deployment and bootstrapping. If the measurement system updates the MA's capabilities, eg with some new Measurement Methods, then the measurement system (& Controller) should know about it. > > The WG is supposed to think about the bootstrapping process but doesn't define a detailed bootstrap protocol (I think the latter is out of scope, on the basis that's it depends on the access/device type, eg use TR-069 for BBF devices etc). > I think so far we (or at least I) have been quite vague about what this means. We could do with some more detailed work, perhaps it would reveal that some useful things don't depend on the access/device type, so could be good for lmap wg to define? > > >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: 05 September 2013 12:57 >> To: Eardley,PL,Philip,TUB8 R >> Cc: lmap@ietf.org >> Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA >> and Controller >> >> Hi, Phil, all, >> >> Some points on this inline... >> >> On 5 Sep 2013, at 12:13 , wrote: >> >>> Another issue: >>> There is no negotiation between the MA and Controller - the >> Controller simply sends the Instruction to the MA, with the details of >> the Measurement Tasks to perform. >>> In general we expect that the measurement system understands the >> capabilities of its MAs (probably there are only one or a few classes >> of MA), so negotiation about the MA's capabilities would have little >> benefit. It would also add complexity to the MA, Controller and Control >> Protocol. >> >> First, there's a separation between negotiation and capabilities >> advertisement. The former allows MAs and Controllers to iteratively >> agree on what the MA can and will do with respect to a given Task; the >> latter provides a method for the MA to tell the Controller what it >> might be willing to do at some point in the future. >> >> Negotiation, as I see it, is significantly more complicated that >> advertisement; in the latter case, a Controller can simply select to >> use the subset of MAs -- the negotiation algorithm is local to the >> Controller in this case, and doesn't touch the protocol at all. >> >> I'm somewhat skeptical that a system relying on static capabilities -- >> i.e. with neither negotiation nor capabilities advertisement -- will >> ever be deployable and manageable. It presumes that all MAs are the >> same, and that their capabilities never change over their lifetimes; >> that the set of basic capabilities presumed to be supported by all/most >> MAs will never change; it also presumes that no MA can support any >> additional measurement services beyond the base profile, which makes it >> difficult for different MA vendors to differentiate their >> implementations. >> >> I know that _discovery_ of MAs is explicitly out of scope to allow >> integration with (access network technology bound) device management >> protocols, but it seems we really need some way to bind what an MA can >> do to its identification. >> >>> It is possible that the MA can't perform the requested Measurement >> Task. So the Control Protocol needs to allow the MA to reply with an >> error code. >> >> This is more useful in use cases where the controller cares about the >> results from a specific MA. In an environment with thousands of MAs >> with varying connectivity, requiring a back channel for errors (and/or >> requiring the Controller to actually _do_ something about this error) >> seems like a lot of overhead for zero actionable insight. >> >>> It has also been suggested that the Controller should be able to ask >> the MA to send a list of all the Measurement Methods that it is capable >> of, in case 'something goes wrong' and the Controller forgets what the >> MA can do. >> >> This would be a nice way to implement capability advertisement without >> linking it to discovery, actually. Downside is you end up with >> something that looks like negotiation on association: discover - >> associate - capability query - capability advertisement response - now >> we can measure something. >> >> Cheers, >> >> Brian > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > From Michael.K.Bugenhagen@centurylink.com Thu Sep 5 06:14:29 2013 Return-Path: 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 A868811E80DF for ; Thu, 5 Sep 2013 06:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] 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 alhC9W8ASg2k for ; Thu, 5 Sep 2013 06:14:24 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id D186111E8128 for ; Thu, 5 Sep 2013 06:14:23 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r85DEFsn019068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Sep 2013 07:14:15 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id D56491E0091; Thu, 5 Sep 2013 07:14:09 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id B26F21E00A8; Thu, 5 Sep 2013 07:14:09 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r85DE9Kk029805; Thu, 5 Sep 2013 07:14:09 -0600 (MDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r85DE8Y7029802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 07:14:08 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.02.0318.001; Thu, 5 Sep 2013 08:14:08 -0500 From: "Bugenhagen, Michael K" To: "'philip.eardley@bt.com'" , "paitken@cisco.com" Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: AQHOqilVkeUpThW4yEGuuPkwMD+qGpm3bfYA//+u/eA= Date: Thu, 5 Sep 2013 13:14:07 +0000 Message-ID: References: <522867E5.3070205@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E047B439Fpodcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:14:29 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E047B439Fpodcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Short and sweet - - I don't think we can't guarantee that a MA initiating a test (co= uld be a customer MA or other) knows the capabilities of the desired target= MA via a controller only scheduling those types of tests. o Therefore In my mind - some peer to peer capability negotiation is requ= ired. This is really what drives a MA to do a "capabilities" / "compatibility" ch= eck on incoming tests. Which immediately drives the codification (standard test na= ming) to enable an efficient . .. can you do test 17alpha.5 with X, Y, Z a= ttributes... Example - I want to test jumbo frames, maybe the MA doesn't do those... (a= sking the group to think about Gig on purpose to make sure we're future pro= ofing here) Regards, Mike From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: Thursday, September 05, 2013 7:56 AM To: paitken@cisco.com Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and C= ontroller I don't think lmap should define a dynamic MA discovery protocol On your "Future" bullet - << Later the MA later discovers that it's not cap= able of performing the test>> I was assuming that the MA understands what Measurement Methods it can do, = so it should know at the time when it gets the Instruction whether it can d= o the test or not. So I'm not that worried about the MA later realising it = can't. My assumption here - the operator of the measurement system checks in the l= ab what Methods can run on which of its types of MAs - it allows some margi= n for error - it definitely doesn't try and operate Methods which will run = ok sometimes and not at other times (when the device containing the MA is "= busy"). If the Result isn't collected or is suspected of being wrong for some reaso= n, then it's marked when the Results are reported. I agree in some circumst= ances the measurement system may want to tell the Controller (the feedback = loop out of scope of lmap to define) Thanks Phil From: Paul Aitken [mailto:paitken@cisco.com] Sent: 05 September 2013 12:16 To: Eardley,PL,Philip,TUB8 R Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and C= ontroller Phil, A controller can't forget what an MA can do unless / untll it first knows..= . so presumably there's a discovery phase where a (new) controller becomes = aware of which MAs are within its control, and what the capabilities of eac= h MA are. This has to be a dynamic process so new MAs can appear (and disap= pear) at any time. Whether the controller discovers MAs, or the MAs announc= e themselves to the controller depends on the protocol, firewalls, etc. See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8 After this there are a couple of failure scenarios: * Immediate: the controller requests an MA perform a test; the MA knows it'= s not capable of performing that test (eg due to a conflict or lack of reso= urces). The MA can immediately indicate an error code to the controller. Th= e controller could request a different test or choose a different MA. * Future: the controller requests an MA perform a test in the future (eg, a= t midnight), or a repeating test (eg, hourly). The MA accepts the test, ind= icating OK to the controller. Later the MA later discovers that it's not ca= pable of performing the test. Depending on the control protocol, there may = or may not be a connection between the MA and the controller. So the MA may= have to indicate an error to the collector - especially if it wants to rep= ort partial results for an incomplete repeating test. If the MA indicates the error to the collector, does the collector need to = tell the controller that the test didn't happen, or only partially happened= ? Aamer and I supposed so, which is why we added the controller / collector= feedback loop. OTOH, if the controller doesn't need to know that the test(= s) didn't happen, then why do we need error codes at all? The controller te= lls an MA to perform the test, and either it does or doesn't... it doesn't = make sense, right? P. Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_A68F3CAC468B2E48BB775ACE2DD99B5E047B439Fpodcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Short and sweet –= ;

 

-&nb= sp;         I don’t = think we can’t guarantee that a MA initiating a test (could be a cust= omer MA or other) knows the capabilities of the desired target MA via a con= troller only scheduling those types of tests.

o   Therefore In m= y mind - some peer to peer capability negotiation is required.

 

This is really what dr= ives a MA to do a “capabilities” / “compatibility” = check on incoming tests.

   &nbs= p;            Which = immediately drives the codification (standard test naming) to enable an eff= icient .  .. can you do test 17alpha.5 with X, Y, Z attributes…<= o:p>

 

Example -  I want= to test jumbo frames, maybe the MA doesn’t do those… (asking t= he group to think about Gig on purpose to make sure we’re future proo= fing here)

 

Regards,

Mike=

 

 

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.o= rg] On Behalf Of philip.eardley@bt.com
Sent: Thursday, September 05, 2013 7:56 AM
To: paitken@cisco.com
Cc: lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between M= A and Controller

 

I don’t t= hink lmap should define a dynamic MA discovery protocol

 

On your “= Future” bullet – << Later the= MA later discovers that it's not capable of performing the test>>

I was assuming = that the MA understands what Measurement Methods it can do, so it should kn= ow at the time when it gets the Instruction whether it can do the test or not. So I’m not that worried about the MA later reali= sing it can’t.

 

My assumption h= ere – the operator of the measurement system checks in the lab what M= ethods can run on which of its types of MAs – it allows some margin for error – it definitely doesn’t try and operate Methods whic= h will run ok sometimes and not at other times (when the device containing = the MA is “busy”).

 

If the Result i= sn’t collected or is suspected of being wrong for some reason, then i= t’s marked when the Results are reported. I agree in some circumstanc= es the measurement system may want to tell the Controller (the feedback loop = out of scope of lmap to define)

 

Thanks

Phil=

 

From: Paul Aitken [mailto:paitken@cisco.com]
Sent: 05 September 2013 12:16
To: Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between M= A and Controller

 

= Phil,

A controller can't forget what an MA can do unless / untll it first knows..= . so presumably there's a discovery phase where a (new) controller becomes = aware of which MAs are within its control, and what the capabilities of eac= h MA are. This has to be a dynamic process so new MAs can appear (and disappear) at any time. Whether the con= troller discovers MAs, or the MAs announce themselves to the controller dep= ends on the protocol, firewalls, etc.

See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8

After this there are a couple of failure scenarios:

* Immediate: the controller requests an MA perform a test; the MA knows it'= s not capable of performing that test (eg due to a conflict or lack of reso= urces). The MA can immediately indicate an error code to the controller. Th= e controller could request a different test or choose a different MA.

* Future: the controller requests an MA perform a test in the future (eg, a= t midnight), or a repeating test (eg, hourly). The MA accepts the test, ind= icating OK to the controller. Later the MA later discovers that it's not ca= pable of performing the test. Depending on the control protocol, there may or may not be a connection between the = MA and the controller. So the MA may have to indicate an error to the colle= ctor - especially if it wants to report partial results for an incomplete r= epeating test.

If the MA indicates the error to the collector, does the collector need to = tell the controller that the test didn't happen, or only partially happened= ? Aamer and I supposed so, which is why we added the controller / collector= feedback loop. OTOH, if the controller doesn't need to know that the test(s) didn't happen, then why do we need e= rror codes at all? The controller tells an MA to perform the test, and eith= er it does or doesn't... it doesn't make sense, right?

P.

Another issue= :

There is no n= egotiation between the MA and Controller - the Controller simply sends the = Instruction to the MA, with the details of the Measurement Tasks to perform.

In general we= expect that the measurement system understands the capabilities of its MAs= (probably there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. I= t would also add complexity to the MA, Controller and Control Protocol.

 =

It is possibl= e that the MA can’t perform the requested Measurement Task. So the Co= ntrol Protocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the M= A to send a list of all the Measurement Methods that it is capable of, in c= ase ‘something goes wrong’ and the Controller forgets what the = MA can do. Comment: this idea hasn’t had much discussion yet, but appears in the Information Model i-d

 =

Thoughts?

Thanks=

phil



_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap

 

--_000_A68F3CAC468B2E48BB775ACE2DD99B5E047B439Fpodcwmbxex505ct_-- From paitken@cisco.com Thu Sep 5 06:33:11 2013 Return-Path: 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 BCB5621F9BA4 for ; Thu, 5 Sep 2013 06:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, 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 nQZpKdnBYoF3 for ; Thu, 5 Sep 2013 06:33:06 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3B21F9C78 for ; Thu, 5 Sep 2013 06:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21667; q=dns/txt; s=iport; t=1378387985; x=1379597585; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=KvBfj02RCDTIOQqC2nNUvBs6Rw2Is8ntK/wUU0/GxNk=; b=SpIX0ITvqFaoy8oWf52ZXXSNoqc2WGac6R4LMGGqNmOttcE3/adbmJAj faWu41+S6KVDFqR5cyG0hj+bzp8kWPnrzs3WGRxoEGrXdqtT+cTLT8YDl DoijMvwn0FZvvpZ6oA+rbQwiU5Od/0BOmMyYUmybMnAp7GVCwM4MVir8Y o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAKWHKFKQ/khR/2dsb2JhbABbgkNENYlYuEGBKBZ0giQBAQEDAQEBASpBCgEFCwsRBAEBChYBBwcJAwIBAgEVHwkIEwEFAgEBh3gGDLoRjhGBTwYBhB0DgVGWJIEvhH2LOoMh X-IronPort-AV: E=Sophos;i="4.90,847,1371081600"; d="scan'208,217";a="17778173" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 05 Sep 2013 13:33:03 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r85DX1U9008920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Sep 2013 13:33:02 GMT Received: from [10.61.220.173] ([10.61.220.173]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r85DWxsc012201; Thu, 5 Sep 2013 14:33:00 +0100 (BST) Message-ID: <5228880C.8070808@cisco.com> Date: Thu, 05 Sep 2013 14:33:00 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: philip.eardley@bt.com References: <522867E5.3070205@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090709020107030106080407" Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:33:11 -0000 This is a multi-part message in MIME format. --------------090709020107030106080407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phil, > I don't think lmap should define a dynamic MA discovery protocol > If I buy a new router or STB, or if I install an app on my mobile device, how is the controller to know that new MAs are available in the network? If the mobile device moves to a different network, how is the controller to know? The device might even move from one controller to another. > On your "Future" bullet -- << Later the MA later discovers that it's > not capable of performing the test>> > > I was assuming that the MA understands what Measurement Methods it can > do, so it should know at the time when it gets the Instruction whether > it can do the test or not. So I'm not that worried about the MA later > realising it can't. > This is not so easily dismissed, since there are many reasons that the MA may be able to accept the test at request time, but quite unable to run it at a later test time. eg, the MA may be resource bound, offline, or not be able to obtain resources from a test peer - none of which it knows at request time unless the test is immediate. > My assumption here -- the operator of the measurement system checks in > the lab what Methods can run on which of its types of MAs -- it allows > some margin for error -- it definitely doesn't try and operate Methods > which will run ok sometimes and not at other times (when the device > containing the MA is "busy"). > When my ISP asks my mobile device to perform some hourly test, how do they know it has enough battery to last? How can they know whether the device will be connected each hour? How can they predict the CPU and memory status at test time? > If the Result isn't collected or is suspected of being wrong for some > reason, then it's marked when the Results are reported. I agree in > some circumstances the measurement system may want to tell the > Controller (the feedback loop out of scope of lmap to define) > Good. P. > Thanks > > Phil > > *From:*Paul Aitken [mailto:paitken@cisco.com] > *Sent:* 05 September 2013 12:16 > *To:* Eardley,PL,Philip,TUB8 R > *Cc:* lmap@ietf.org > *Subject:* Re: [lmap] LMAP Framework issue #3 No negotiation between > MA and Controller > > Phil, > > A controller can't forget what an MA can do unless / untll it first > knows... so presumably there's a discovery phase where a (new) > controller becomes aware of which MAs are within its control, and what > the capabilities of each MA are. This has to be a dynamic process so > new MAs can appear (and disappear) at any time. Whether the controller > discovers MAs, or the MAs announce themselves to the controller > depends on the protocol, firewalls, etc. > > See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8 > > > After this there are a couple of failure scenarios: > > * Immediate: the controller requests an MA perform a test; the MA > knows it's not capable of performing that test (eg due to a conflict > or lack of resources). The MA can immediately indicate an error code > to the controller. The controller could request a different test or > choose a different MA. > > * Future: the controller requests an MA perform a test in the future > (eg, at midnight), or a repeating test (eg, hourly). The MA accepts > the test, indicating OK to the controller. Later the MA later > discovers that it's not capable of performing the test. Depending on > the control protocol, there may or may not be a connection between the > MA and the controller. So the MA may have to indicate an error to the > collector - especially if it wants to report partial results for an > incomplete repeating test. > > If the MA indicates the error to the collector, does the collector > need to tell the controller that the test didn't happen, or only > partially happened? Aamer and I supposed so, which is why we added the > controller / collector feedback loop. OTOH, if the controller doesn't > need to know that the test(s) didn't happen, then why do we need error > codes at all? The controller tells an MA to perform the test, and > either it does or doesn't... it doesn't make sense, right? > > P. > > Another issue: > > There is no negotiation between the MA and Controller - the > Controller simply sends the Instruction to the MA, with the > details of the Measurement Tasks to perform. > > In general we expect that the measurement system understands the > capabilities of its MAs (probably there are only one or a few > classes of MA), so negotiation about the MA's capabilities would > have little benefit. It would also add complexity to the MA, > Controller and Control Protocol. > > It is possible that the MA can't perform the requested Measurement > Task. So the Control Protocol needs to allow the MA to reply with > an error code. It has also been suggested that the Controller > should be able to ask the MA to send a list of all the Measurement > Methods that it is capable of, in case 'something goes wrong' and > the Controller forgets what the MA can do. Comment: this idea > hasn't had much discussion yet, but appears in the Information > Model i-d > > Thoughts? > > Thanks > > phil > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > --------------090709020107030106080407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Phil,

I don’t think lmap should define a dynamic MA discovery protocol


If I buy a new router or STB, or if I install an app on my mobile device, how is the controller to know that new MAs are available in the network?

If the mobile device moves to a different network, how is the controller to know? The device might even move from one controller to another.


On your “Future” bullet – << Later the MA later discovers that it's not capable of performing the test>>

I was assuming that the MA understands what Measurement Methods it can do, so it should know at the time when it gets the Instruction whether it can do the test or not. So I’m not that worried about the MA later realising it can’t.


This is not so easily dismissed, since there are many reasons that the MA may be able to accept the test at request time, but quite unable to run it at a later test time. eg, the MA may be resource bound, offline, or not be able to obtain resources from a test peer - none of which it knows at request time unless the test is immediate.


My assumption here – the operator of the measurement system checks in the lab what Methods can run on which of its types of MAs – it allows some margin for error – it definitely doesn’t try and operate Methods which will run ok sometimes and not at other times (when the device containing the MA is “busy”).


When my ISP asks my mobile device to perform some hourly test, how do they know it has enough battery to last? How can they know whether the device will be connected each hour? How can they predict the CPU and memory status at test time?


If the Result isn’t collected or is suspected of being wrong for some reason, then it’s marked when the Results are reported. I agree in some circumstances the measurement system may want to tell the Controller (the feedback loop out of scope of lmap to define)


Good.

P.

 

Thanks

Phil

 

From: Paul Aitken [mailto:paitken@cisco.com]
Sent: 05 September 2013 12:16
To: Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

 

Phil,

A controller can't forget what an MA can do unless / untll it first knows... so presumably there's a discovery phase where a (new) controller becomes aware of which MAs are within its control, and what the capabilities of each MA are. This has to be a dynamic process so new MAs can appear (and disappear) at any time. Whether the controller discovers MAs, or the MAs announce themselves to the controller depends on the protocol, firewalls, etc.

See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8


After this there are a couple of failure scenarios:

* Immediate: the controller requests an MA perform a test; the MA knows it's not capable of performing that test (eg due to a conflict or lack of resources). The MA can immediately indicate an error code to the controller. The controller could request a different test or choose a different MA.

* Future: the controller requests an MA perform a test in the future (eg, at midnight), or a repeating test (eg, hourly). The MA accepts the test, indicating OK to the controller. Later the MA later discovers that it's not capable of performing the test. Depending on the control protocol, there may or may not be a connection between the MA and the controller. So the MA may have to indicate an error to the collector - especially if it wants to report partial results for an incomplete repeating test.

If the MA indicates the error to the collector, does the collector need to tell the controller that the test didn't happen, or only partially happened? Aamer and I supposed so, which is why we added the controller / collector feedback loop. OTOH, if the controller doesn't need to know that the test(s) didn't happen, then why do we need error codes at all? The controller tells an MA to perform the test, and either it does or doesn't... it doesn't make sense, right?

P.

Another issue:

There is no negotiation between the MA and Controller - the Controller simply sends the Instruction to the MA, with the details of the Measurement Tasks to perform.

In general we expect that the measurement system understands the capabilities of its MAs (probably there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. It would also add complexity to the MA, Controller and Control Protocol.

 

It is possible that the MA can’t perform the requested Measurement Task. So the Control Protocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to send a list of all the Measurement Methods that it is capable of, in case ‘something goes wrong’ and the Controller forgets what the MA can do. Comment: this idea hasn’t had much discussion yet, but appears in the Information Model i-d

 

Thoughts?

Thanks

phil




_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap

 


--------------090709020107030106080407-- From trammell@tik.ee.ethz.ch Thu Sep 5 06:57:23 2013 Return-Path: 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 E2E2211E819F for ; Thu, 5 Sep 2013 06:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] 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 6pEJO-W0G0HD for ; Thu, 5 Sep 2013 06:57:19 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 64AC511E819C for ; Thu, 5 Sep 2013 06:57:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5E345D9305; Thu, 5 Sep 2013 15:57:08 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RaxaaIZGqXqE; Thu, 5 Sep 2013 15:57:08 +0200 (MEST) Received: from public-docking-pat-etx-0378.ethz.ch (public-docking-pat-etx-0378.ethz.ch [10.2.113.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E3F81D9300; Thu, 5 Sep 2013 15:57:07 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: Date: Thu, 5 Sep 2013 15:57:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <551839F7-A7E1-4DB7-85CE-1EE9442452D5@tik.ee.ethz.ch> References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> To: X-Mailer: Apple Mail (2.1508) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:57:24 -0000 On 5 Sep 2013, at 14:30 , wrote: >> Negotiation, as I see it, is significantly more complicated that >> advertisement; > Agree. >=20 >> I'm somewhat skeptical that a system relying on static capabilities = -- >> i.e. with neither negotiation nor capabilities advertisement -- will >> ever be deployable and manageable. >=20 > My assumption (which I should have stated!): > the measurement system needs to know the capabilities of its MAs. I'd add the following assumption: the capabilities of the MAs are (1) = heterogeneous and (2) dynamic. > it will do this as part of deployment and bootstrapping. If the = measurement system updates the MA's capabilities, eg with some new = Measurement Methods, then the measurement system (& Controller) should = know about it. >=20 > The WG is supposed to think about the bootstrapping process but = doesn't define a detailed bootstrap protocol (I think the latter is out = of scope, on the basis that's it depends on the access/device type, eg = use TR-069 for BBF devices etc).=20 Agree; this makes sense. My question: how much information can we easily = transfer about the MA via TR-069 etc.? > I think so far we (or at least I) have been quite vague about what = this means. We could do with some more detailed work, perhaps it would = reveal that some useful things don't depend on the access/device type, = so could be good for lmap wg to define? Well, the basic things you're trying to measure -- the underlying ideal = goals of the measurement activity, as opposed to the algorithms and = techniques, should be universal across access technologies; additional = access-technique-specific parameters can certainly also be advertised as = capabilities. Cheers, Brian >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: 05 September 2013 12:57 >> To: Eardley,PL,Philip,TUB8 R >> Cc: lmap@ietf.org >> Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA >> and Controller >>=20 >> Hi, Phil, all, >>=20 >> Some points on this inline... >>=20 >> On 5 Sep 2013, at 12:13 , wrote: >>=20 >>> Another issue: >>> There is no negotiation between the MA and Controller - the >> Controller simply sends the Instruction to the MA, with the details = of >> the Measurement Tasks to perform. >>> In general we expect that the measurement system understands the >> capabilities of its MAs (probably there are only one or a few classes >> of MA), so negotiation about the MA's capabilities would have little >> benefit. It would also add complexity to the MA, Controller and = Control >> Protocol. >>=20 >> First, there's a separation between negotiation and capabilities >> advertisement. The former allows MAs and Controllers to iteratively >> agree on what the MA can and will do with respect to a given Task; = the >> latter provides a method for the MA to tell the Controller what it >> might be willing to do at some point in the future. >>=20 >> Negotiation, as I see it, is significantly more complicated that >> advertisement; in the latter case, a Controller can simply select to >> use the subset of MAs -- the negotiation algorithm is local to the >> Controller in this case, and doesn't touch the protocol at all. >>=20 >> I'm somewhat skeptical that a system relying on static capabilities = -- >> i.e. with neither negotiation nor capabilities advertisement -- will >> ever be deployable and manageable. It presumes that all MAs are the >> same, and that their capabilities never change over their lifetimes; >> that the set of basic capabilities presumed to be supported by = all/most >> MAs will never change; it also presumes that no MA can support any >> additional measurement services beyond the base profile, which makes = it >> difficult for different MA vendors to differentiate their >> implementations. >>=20 >> I know that _discovery_ of MAs is explicitly out of scope to allow >> integration with (access network technology bound) device management >> protocols, but it seems we really need some way to bind what an MA = can >> do to its identification. >>=20 >>> It is possible that the MA can't perform the requested Measurement >> Task. So the Control Protocol needs to allow the MA to reply with an >> error code. >>=20 >> This is more useful in use cases where the controller cares about the >> results from a specific MA. In an environment with thousands of MAs >> with varying connectivity, requiring a back channel for errors = (and/or >> requiring the Controller to actually _do_ something about this error) >> seems like a lot of overhead for zero actionable insight. >>=20 >>> It has also been suggested that the Controller should be able to ask >> the MA to send a list of all the Measurement Methods that it is = capable >> of, in case 'something goes wrong' and the Controller forgets what = the >> MA can do. >>=20 >> This would be a nice way to implement capability advertisement = without >> linking it to discovery, actually. Downside is you end up with >> something that looks like negotiation on association: discover - >> associate - capability query - capability advertisement response - = now >> we can measure something. >>=20 >> Cheers, >>=20 >> Brian >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Thu Sep 5 06:58:23 2013 Return-Path: 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 E463621F9A1C for ; Thu, 5 Sep 2013 06:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6StlUWRYYpMH for ; Thu, 5 Sep 2013 06:58:12 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE7921F8F24 for ; Thu, 5 Sep 2013 06:58:12 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 4fd88225.2aaad7a18940.1299919.00-528.3587451.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 05 Sep 2013 13:58:12 +0000 (UTC) X-MXL-Hash: 52288df429155ab1-5099d6e17403064735eb3f68401f1a178e9c91c2 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id fed88225.0.1299856.00-453.3587240.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 05 Sep 2013 13:58:08 +0000 (UTC) X-MXL-Hash: 52288df040b43bec-5def0c597c21b08cb56fee601b0efcbc7ddb0bf0 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r85Dw6He002003; Thu, 5 Sep 2013 09:58:06 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r85DvtAm001861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Sep 2013 09:58:02 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (GAALPA1MSGHUB9A.itservices.sbc.com [130.8.36.87]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 5 Sep 2013 13:57:45 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.03.0158.001; Thu, 5 Sep 2013 09:57:45 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: AQHOqjPJrjThnUMrtEK9647rdf2qjZm3IzZw Date: Thu, 5 Sep 2013 13:57:44 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.249.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=W7WPo2qk c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=VXDTItfqnpQA:10 a=LJSe2eOOjj8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=GFkljcnKXWEA:10 a=_U8qML52WjQsHIvqM10A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:58:23 -0000 Not sure which email in this thread to start from, so I just cleaned out al= l other text... Advertisement: This is a really simple thing to do, and any good control protocol with a w= ell-designed data model should be perfectly capable of this. It is not part= of bootstrap. For example, if TR-069 were being used as the control protocol (and, yes, I= 'm talking about Control and not bootstrap), there would be an xml paramete= r that lists capabilities, as well as xml parameters that match up to the = enabling/disabling/execution of these capabilities, and setting of specific= parameters associated with these capabilities. Via this exemplary TR-069 i= nterface, the Controller can request the MA tell the Controller (1) the ent= ire data model structure (every single xml parameter) and (2) the current v= alues of these xml parameters (e.g., the current value of a capability list= xml parameter). It's not necessary to get this info every time. Important = changes can be "evented", so the Controller is informed either that changes= have occurred, and even what changes have occurred.=20 IMO, lmap should not recommend a protocol that isn't capable of such incred= ibly basic functionality. Negotiation: I don't know that I would call it a negotiation as much as the MA having pr= oper ways to tell the Controller "No". Again, using TR-069 as an example, i= f the Controller tells the MA to set xml parameters that the MA doesn't hav= e in its TR-069 data model, then the MA can say "No, I don't have those par= ameters." If the Controller tells the MA to set xml parameters that have be= en locked so they cannot be written to, then the MA tells the Controller "N= o, those are locked". If there is some temporary reason the MA can't comply= , then the MA needs to tell the Controller "No, not right now".=20 Similarly, if a test were scheduled to be run by the Controller, and the MA= doesn't run it for some reason, there should be an xml parameter that give= s the reason why the test wasn't run (a status or result parameter). The al= lowed values defined for this parameter need to provide the necessary level= of information to the Controller. When the Controller reads the value of t= hat parameter, it gets the info it needs. Since I know that TR-069 can easily do advertisement and negotiation with a= well-designed data model (and, yes, in TR-069 this level of communication = is done through data model parameters and their values and not through spec= ific/different RPCs or RPC error messages), I'm not understanding why ther= e's debate about whether or not these should be criteria in Control protoco= l selection and requirements when doing that protocol's data model design. = IMO, of course they're required. Barbara From philip.eardley@bt.com Thu Sep 5 07:04:36 2013 Return-Path: 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 ECBBC21F93F3 for ; Thu, 5 Sep 2013 07:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.11 X-Spam-Level: X-Spam-Status: No, score=-103.11 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 flxr6J4TsBNZ for ; Thu, 5 Sep 2013 07:04:32 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 5A26F21E8096 for ; Thu, 5 Sep 2013 07:04:25 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 5 Sep 2013 15:04:23 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 5 Sep 2013 15:04:23 +0100 From: To: Date: Thu, 5 Sep 2013 15:04:21 +0100 Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: Ac6qPHPsRAJde7FxThKveANUVF6X6gAAm5wQ Message-ID: References: <522867E5.3070205@cisco.com> <5228880C.8070808@cisco.com> In-Reply-To: <5228880C.8070808@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411ED9EMV67UKRDdoma_" MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:04:37 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411ED9EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Couple of comments inline thanks phil From: Paul Aitken [mailto:paitken@cisco.com] Sent: 05 September 2013 14:33 To: Eardley,PL,Philip,TUB8 R Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and C= ontroller Phil, I don't think lmap should define a dynamic MA discovery protocol If I buy a new router or STB, or if I install an app on my mobile device, h= ow is the controller to know that new MAs are available in the network? If the mobile device moves to a different network, how is the controller to= know? The device might even move from one controller to another. [phil] yes, something needs to handle this. I'm suggesting this is access/d= evice type specific - eg BBF protocol for a broadband forum device, eg an a= pp you download to your mobile etc. so not an lmap feature. On your "Future" bullet - << Later the MA later discovers that it's not cap= able of performing the test>> I was assuming that the MA understands what Measurement Methods it can do, = so it should know at the time when it gets the Instruction whether it can d= o the test or not. So I'm not that worried about the MA later realising it = can't. This is not so easily dismissed, since there are many reasons that the MA m= ay be able to accept the test at request time, but quite unable to run it a= t a later test time. eg, the MA may be resource bound, offline, or not be a= ble to obtain resources from a test peer - none of which it knows at reques= t time unless the test is immediate. [phil] I think it's a bad idea to try and cope with the MA sometimes lackin= g CPU etc resources to run a test. The test should be designed and checked = in the lab such that the MA can run it except under the most unusual case (= then maybe the MA sends an error, maybe it does nothing). If the MA is offl= ine, then I guess it can't send an error msg. where appropriate the Measure= ment Method will define the initial part to check whether the Peer has enou= gh resources to run the test - this is handled similarly to the case where = the MA detects that there's user traffic so shouldn't run the test. I guess= resources could include battery life. I think probably the Method should d= efine what to do - for example delay the test and re-try. My view is that the MA should act autonomously - it gets instructed what te= st to run and when, then it gets on with it. Negotiation back and forth wou= ld add a lot to the complexity and personally I don't see much gain - this = is supposed to be something simple to do. My assumption here - the operator of the measurement system checks in the l= ab what Methods can run on which of its types of MAs - it allows some margi= n for error - it definitely doesn't try and operate Methods which will run = ok sometimes and not at other times (when the device containing the MA is "= busy"). When my ISP asks my mobile device to perform some hourly test, how do they = know it has enough battery to last? How can they know whether the device wi= ll be connected each hour? How can they predict the CPU and memory status a= t test time? If the Result isn't collected or is suspected of being wrong for some reaso= n, then it's marked when the Results are reported. I agree in some circumst= ances the measurement system may want to tell the Controller (the feedback = loop out of scope of lmap to define) Good. P. Thanks Phil From: Paul Aitken [mailto:paitken@cisco.com] Sent: 05 September 2013 12:16 To: Eardley,PL,Philip,TUB8 R Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and C= ontroller Phil, A controller can't forget what an MA can do unless / untll it first knows..= . so presumably there's a discovery phase where a (new) controller becomes = aware of which MAs are within its control, and what the capabilities of eac= h MA are. This has to be a dynamic process so new MAs can appear (and disap= pear) at any time. Whether the controller discovers MAs, or the MAs announc= e themselves to the controller depends on the protocol, firewalls, etc. See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8 After this there are a couple of failure scenarios: * Immediate: the controller requests an MA perform a test; the MA knows it'= s not capable of performing that test (eg due to a conflict or lack of reso= urces). The MA can immediately indicate an error code to the controller. Th= e controller could request a different test or choose a different MA. * Future: the controller requests an MA perform a test in the future (eg, a= t midnight), or a repeating test (eg, hourly). The MA accepts the test, ind= icating OK to the controller. Later the MA later discovers that it's not ca= pable of performing the test. Depending on the control protocol, there may = or may not be a connection between the MA and the controller. So the MA may= have to indicate an error to the collector - especially if it wants to rep= ort partial results for an incomplete repeating test. If the MA indicates the error to the collector, does the collector need to = tell the controller that the test didn't happen, or only partially happened= ? Aamer and I supposed so, which is why we added the controller / collector= feedback loop. OTOH, if the controller doesn't need to know that the test(= s) didn't happen, then why do we need error codes at all? The controller te= lls an MA to perform the test, and either it does or doesn't... it doesn't = make sense, right? P. Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411ED9EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Couple of comments inline

tha= nks

phil

<= p class=3DMsoNormal> 

From:<= /span> Paul Aitken [ma= ilto:paitken@cisco.com]
Sent: 05 September 2013 14:33
To:<= /b> Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org
Subject:= Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controlle= r

 

Phil,=

I don’t think lmap should define a dynamic MA discov= ery protocol


If I buy a new router or STB, or if I install an app on= my mobile device, how is the controller to know that new MAs are available= in the network?

If the mobile device moves to a different network, = how is the controller to know? The device might even move from one controll= er to another.

[phil] yes, = something needs to handle this. I’m suggesting this is access/device = type specific – eg BBF protocol for a broadband forum device, eg an a= pp you download to your mobile etc. so not an lmap feature.

On your= “Future” bullet – << Later the MA later dis= covers that it's not capable of performing the test>>

I was assuming that the MA understands what = Measurement Methods it can do, so it should know at the time when it gets t= he Instruction whether it can do the test or not. So I’m not that wor= ried about the MA later realising it can’t.


This is not so easily dismisse= d, since there are many reasons that the MA may be able to accept the test = at request time, but quite unable to run it at a later test time. eg, the M= A may be resource bound, offline, or not be able to obtain resources from a= test peer - none of which it knows at request time unless the test is imme= diate.

[phil] I think it= 217;s a bad idea to try and cope with the MA sometimes lacking CPU etc reso= urces to run a test. The test should be designed and checked in the lab suc= h that the MA can run it except under the most unusual case (then maybe the= MA sends an error, maybe it does nothing). If the MA is offline, then I gu= ess it can’t send an error msg. where appropriate the Measurement Met= hod will define the initial part to check whether the Peer has enough resou= rces to run the test – this is handled similarly to the case where th= e MA detects that there’s user traffic so shouldn’t run the tes= t. I guess resources could include battery life. I think probably the Metho= d should define what to do – for example delay the test and re-try.

=  

My view is that the MA should act autonomously – it gets inst= ructed what test to run and when, then it gets on with it. Negotiation back= and forth would add a lot to the complexity and personally I don’t s= ee much gain – this is supposed to be something simple to do.

&= nbsp;

My assumption here = 211; the operator of the measurement system checks in the lab what Methods = can run on which of its types of MAs – it allows some margin for erro= r – it definitely doesn’t try and operate Methods which will ru= n ok sometimes and not at other times (when the device containing the MA is= “busy”).


When my ISP asks my mobile device to perform some hourly te= st, how do they know it has enough battery to last? How can they know wheth= er the device will be connected each hour? How can they predict the CPU and= memory status at test time?



If the Result isn’t collected or is suspected of being= wrong for some reason, then it’s marked when the Results are reporte= d. I agree in some circumstances the measurement system may want to tell th= e Controller (the feedback loop out of scope of lmap to define)=


Good.

P.

 

Thanks

Phil

 <= /o:p>

From: Paul Aitken [mailto= :paitken@cisco.com]
Sent: 05 September 2013 12:16
To:<= /b> Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 No= negotiation between MA and Controller

 

Phil,

A controller can't forget what an MA can = do unless / untll it first knows... so presumably there's a discovery phase= where a (new) controller becomes aware of which MAs are within its control= , and what the capabilities of each MA are. This has to be a dynamic proces= s so new MAs can appear (and disappear) at any time. Whether the controller= discovers MAs, or the MAs announce themselves to the controller depends on= the protocol, firewalls, etc.

See http://tools.ietf.org/html= /draft-akhter-lmap-framework-00#section-3.8


After this there= are a couple of failure scenarios:

* Immediate: the controller requ= ests an MA perform a test; the MA knows it's not capable of performing that= test (eg due to a conflict or lack of resources). The MA can immediately i= ndicate an error code to the controller. The controller could request a dif= ferent test or choose a different MA.

* Future: the controller reque= sts an MA perform a test in the future (eg, at midnight), or a repeating te= st (eg, hourly). The MA accepts the test, indicating OK to the controller. = Later the MA later discovers that it's not capable of performing the test. = Depending on the control protocol, there may or may not be a connection bet= ween the MA and the controller. So the MA may have to indicate an error to = the collector - especially if it wants to report partial results for an inc= omplete repeating test.

If the MA indicates the error to the collect= or, does the collector need to tell the controller that the test didn't hap= pen, or only partially happened? Aamer and I supposed so, which is why we a= dded the controller / collector feedback loop. OTOH, if the controller does= n't need to know that the test(s) didn't happen, then why do we need error = codes at all? The controller tells an MA to perform the test, and either it= does or doesn't... it doesn't make sense, right?

P.


Another issue:

= Ther= e is no negotiation between the MA and Controller - the Controller simply s= ends the Instruction to the MA, with the details of the Measurement Tasks t= o perform.

In general we expect that= the measurement system understands the capabilities of its MAs (probably t= here are only one or a few classes of MA), so negotiation about the MA̵= 7;s capabilities would have little benefit. It would also add complexity to= the MA, Controller and Control Protocol.

 

It is possible that the = MA can’t perform the requested Measurement Task. So the Control Proto= col needs to allow the MA to reply with an error code. It has also been sug= gested that the Controller should be able to ask the MA to send a list of a= ll the Measurement Methods that it is capable of, in case ‘something = goes wrong’ and the Controller forgets what the MA can do. Comment: t= his idea hasn’t had much discussion yet, but appears in the Informati= on Model i-d

 =

Thoughts?

<= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>Thank= s

phil





<= /o:p>

_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap=

 

 

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9411ED9EMV67UKRDdoma_-- From Michael.K.Bugenhagen@centurylink.com Thu Sep 5 07:05:00 2013 Return-Path: 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 7E28021F9A6A for ; Thu, 5 Sep 2013 07:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 K4o6WAJ56jF0 for ; Thu, 5 Sep 2013 07:04:52 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 55EE721E80B0 for ; Thu, 5 Sep 2013 07:04:52 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r85E4k0c021121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Sep 2013 09:04:47 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 9B6491E0060; Thu, 5 Sep 2013 08:04:41 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 6E9A11E0068; Thu, 5 Sep 2013 08:04:41 -0600 (MDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r85E4eQK001169; Thu, 5 Sep 2013 09:04:40 -0500 (CDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r85E4eMg001144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 09:04:40 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.02.0318.001; Thu, 5 Sep 2013 09:04:40 -0500 From: "Bugenhagen, Michael K" To: "'STARK, BARBARA H'" , "philip.eardley@bt.com" Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: AQHOqjPGxJ8G+5lir0OtLdLMMxyTYpm3fzMA//+tpwA= Date: Thu, 5 Sep 2013 14:04:39 +0000 Message-ID: References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:05:00 -0000 I concur there needs to be a discovery method, maybe two methods, one for t= he home network, and one for the larger Internet. Either way a standard "how do you find X" needs to be there for Agents... When a Agent doesn't have a clear registry advertising is required. -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STA= RK, BARBARA H Sent: Thursday, September 05, 2013 8:58 AM To: philip.eardley@bt.com Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and C= ontroller Not sure which email in this thread to start from, so I just cleaned out al= l other text... Advertisement: This is a really simple thing to do, and any good control protocol with a w= ell-designed data model should be perfectly capable of this. It is not part= of bootstrap. For example, if TR-069 were being used as the control protocol (and, yes, I= 'm talking about Control and not bootstrap), there would be an xml paramete= r that lists capabilities, as well as xml parameters that match up to the = enabling/disabling/execution of these capabilities, and setting of specific= parameters associated with these capabilities. Via this exemplary TR-069 i= nterface, the Controller can request the MA tell the Controller (1) the ent= ire data model structure (every single xml parameter) and (2) the current v= alues of these xml parameters (e.g., the current value of a capability list= xml parameter). It's not necessary to get this info every time. Important = changes can be "evented", so the Controller is informed either that changes= have occurred, and even what changes have occurred.=20 IMO, lmap should not recommend a protocol that isn't capable of such incred= ibly basic functionality. Negotiation: I don't know that I would call it a negotiation as much as the MA having pr= oper ways to tell the Controller "No". Again, using TR-069 as an example, i= f the Controller tells the MA to set xml parameters that the MA doesn't hav= e in its TR-069 data model, then the MA can say "No, I don't have those par= ameters." If the Controller tells the MA to set xml parameters that have be= en locked so they cannot be written to, then the MA tells the Controller "N= o, those are locked". If there is some temporary reason the MA can't comply= , then the MA needs to tell the Controller "No, not right now".=20 Similarly, if a test were scheduled to be run by the Controller, and the MA= doesn't run it for some reason, there should be an xml parameter that give= s the reason why the test wasn't run (a status or result parameter). The al= lowed values defined for this parameter need to provide the necessary level= of information to the Controller. When the Controller reads the value of t= hat parameter, it gets the info it needs. Since I know that TR-069 can easily do advertisement and negotiation with a= well-designed data model (and, yes, in TR-069 this level of communication = is done through data model parameters and their values and not through spec= ific/different RPCs or RPC error messages), I'm not understanding why ther= e's debate about whether or not these should be criteria in Control protoco= l selection and requirements when doing that protocol's data model design. = IMO, of course they're required. Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Thu Sep 5 07:27:19 2013 Return-Path: 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 F064A21E80FB for ; Thu, 5 Sep 2013 07:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 K4DPeqY7SG+4 for ; Thu, 5 Sep 2013 07:27:11 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id AB2A621E80FF for ; Thu, 5 Sep 2013 07:27:10 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id eb498225.66280940.7110101.00-592.19464649.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 05 Sep 2013 14:27:10 +0000 (UTC) X-MXL-Hash: 522894be479b3cae-a3e5d2e687684b961acddebd9e911e8333df316f Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 5b498225.0.7110049.00-391.19464475.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 05 Sep 2013 14:27:02 +0000 (UTC) X-MXL-Hash: 522894b66b78a559-5ea6cb0b750b73abb78c8e9406b437afd3ac789f Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r85ER0Y2001658; Thu, 5 Sep 2013 10:27:01 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r85EQtuG001592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Sep 2013 10:26:56 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 5 Sep 2013 14:26:45 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0158.001; Thu, 5 Sep 2013 10:26:45 -0400 From: "STARK, BARBARA H" To: Brian Trammell , "philip.eardley@bt.com" Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: AQHOqj/iF6DbItr2CEGCUI9EB9v4tpm3LOVg Date: Thu, 5 Sep 2013 14:26:44 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303557CB@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <551839F7-A7E1-4DB7-85CE-1EE9442452D5@tik.ee.ethz.ch> In-Reply-To: <551839F7-A7E1-4DB7-85CE-1EE9442452D5@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.249.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=E6l6U9hl c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=VXDTItfqnpQA:10 a=LJSe2eOOjj8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=GFkljcnKXWEA:10 a=OrviL0f0F5Lx4gSW-VIA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:27:19 -0000 > Agree; this makes sense. My question: how much information can we easily > transfer about the MA via TR-069 etc.? Note: TR-069 can be used both for bootstrap as well as Control. I have ever= y intention of making sure that a TR-069 data model gets defined based on t= he lmap information model, and extended to include elements specifically de= fined in BBF (e.g., if there are access PHY-specific tests -- for every acc= ess PHY people would like to see included in the data model, since TR-069 i= tself only depends on IP connectivity). I would probably limit metadata about an MA (bootstrap xml parameter data m= odel) to just be the elements needed to get the MA installed, running, and = communicating with a Controller. However, the "communicating with a Controller" metadata would be optional t= o have or use. In many cases, the MA will come pre-configured with the Cont= roller information. Discovery is accomplished by the MA "calling home" to t= he configured Controller. For example: 3rd party has MA software available for user to download and i= nstall on a PC. User downloads, agrees to terms and conditions, installs, a= nd runs the MA. Therefore, the user is the bootstrapper. The MA comes pre-c= onfigured with that 3rd party's Controller info, so when the user runs it, = the MA "calls home" and is discovered. In this case, the Controller info is= internal to the MA (not exposed metadata). There is also the case where the user is asked to help configure the MA (ag= ain, the user is the bootstrapper). In this case, the Controller info is, e= ffectively, exposed metadata.=20 And there is the case where the service provider puts a MA on a provided ho= me router. The service provider may choose to expose the Controller configu= ration metadata to the bootstrap protocol, or have that info pre-configured= in the MA. I would recommend that whether or not the Controller metadata is exposed to= the bootstrap mechanism, or pre-configured, it must be settable by the Con= troller. Therefore, Controller info needs to be included in the information model. Barbara From bs7652@att.com Thu Sep 5 07:53:52 2013 Return-Path: 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 0DA4721F9C17 for ; Thu, 5 Sep 2013 07:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FSMP1+jIsGQP for ; Thu, 5 Sep 2013 07:53:44 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA6711E80EC for ; Thu, 5 Sep 2013 07:53:44 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 8fa98225.2aaafd254940.528.00-570.1549.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 05 Sep 2013 14:53:44 +0000 (UTC) X-MXL-Hash: 52289af86f8f37b6-b4eed7db824982760e0fcfa2adcf7ab3ecefaf60 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 0fa98225.0.427.00-464.1231.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 05 Sep 2013 14:53:37 +0000 (UTC) X-MXL-Hash: 52289af139a6696b-3e083c3b1a002eaa9a494b97d9ee64b1dc7a3ac3 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r85EraZV030776; Thu, 5 Sep 2013 10:53:36 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r85ErS0E030670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Sep 2013 10:53:30 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (GAALPA1MSGHUB9A.itservices.sbc.com [130.8.36.87]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 5 Sep 2013 14:53:21 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.03.0158.001; Thu, 5 Sep 2013 10:53:21 -0400 From: "STARK, BARBARA H" To: "Bugenhagen, Michael K" , "philip.eardley@bt.com" Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: AQHOqjPJrjThnUMrtEK9647rdf2qjZm3IzZwgABNKYD//8ctYA== Date: Thu, 5 Sep 2013 14:53:20 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303557FA@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.249.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=FdKAMuC6 c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=VXDTItfqnpQA:10 a=LJSe2eOOjj8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=GFkljcnKXWEA:10 a=g28rJSj2OKPK-L29adgA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:53:52 -0000 > I concur there needs to be a discovery method, maybe two methods, one for > the home network, and one for the larger Internet. >=20 > Either way a standard "how do you find X" needs to be there for Agents... > When a Agent doesn't have a clear registry advertising is required. Hmm. This seems to be expanding the concept of "discovery" beyond what I sa= w in previous posts. I thought the "discovery" discussion was in the context of a Controller "di= scovering" the MAs that it can control, and an MA "discovering" who its Con= troller was supposed to be. As I mentioned in my last email, I think that t= hese are best and most easily handled through either bootstrap (which could= be via user or protocol and is out of scope) or pre-configuration. It woul= d be possible to design more robust and incredibly complex discovery mechan= isms (and then the robust and complex security needed to prevent abuse of s= uch mechanisms), but I'm really not seeing good justification for something= more complex at this time. I'm only focusing on the case where the Controller is somewhere in the Inte= rnet and not in the home network. I've sort of concluded that the best place to deal with internal-to-the-hom= e-network mechanisms in IETF is homenet and not lmap.=20 Barbara From sharam.hakimi@exfo.com Thu Sep 5 12:08:00 2013 Return-Path: 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 8518621E8150 for ; Thu, 5 Sep 2013 12:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] 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 oNrTtPOXOOcz for ; Thu, 5 Sep 2013 12:07:48 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB5821E814E for ; Thu, 5 Sep 2013 12:07:46 -0700 (PDT) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Sep 2013 15:07:44 -0400 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Sep 2013 15:07:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CEAA6B.2469B400" Date: Thu, 5 Sep 2013 15:08:14 -0400 Message-ID: <084CDC75FEC1E640B60338273BEACDFA0279D9EC@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: Ac6qPHPsRAJde7FxThKveANUVF6X6gAAm5wQAAq130A= References: <522867E5.3070205@cisco.com><5228880C.8070808@cisco.com> From: "Sharam Hakimi" To: , X-OriginalArrivalTime: 05 Sep 2013 19:07:45.0112 (UTC) FILETIME=[34026D80:01CEAA6B] Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 19:08:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CEAA6B.2469B400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems that there are major questions on USE cases. Whether it is Discovery/Registration, Bootstrapped or self contained, finding MA capabilities, Test is MA initiated or Controller initiated, to who and how to report the results, what test authorization or CAC accomplishes, would be best to agree on a set of use cases and then apply the details. =20 Sharam =20 =20 From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 05, 2013 10:04 AM To: paitken@cisco.com Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller =20 Couple of comments inline thanks phil =20 From: Paul Aitken [mailto:paitken@cisco.com]=20 Sent: 05 September 2013 14:33 To: Eardley,PL,Philip,TUB8 R Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller =20 Phil, I don't think lmap should define a dynamic MA discovery protocol If I buy a new router or STB, or if I install an app on my mobile device, how is the controller to know that new MAs are available in the network? If the mobile device moves to a different network, how is the controller to know? The device might even move from one controller to another. [phil] yes, something needs to handle this. I'm suggesting this is access/device type specific - eg BBF protocol for a broadband forum device, eg an app you download to your mobile etc. so not an lmap feature.=20 On your "Future" bullet - << Later the MA later discovers that it's not capable of performing the test>> I was assuming that the MA understands what Measurement Methods it can do, so it should know at the time when it gets the Instruction whether it can do the test or not. So I'm not that worried about the MA later realising it can't.=20 This is not so easily dismissed, since there are many reasons that the MA may be able to accept the test at request time, but quite unable to run it at a later test time. eg, the MA may be resource bound, offline, or not be able to obtain resources from a test peer - none of which it knows at request time unless the test is immediate. [phil] I think it's a bad idea to try and cope with the MA sometimes lacking CPU etc resources to run a test. The test should be designed and checked in the lab such that the MA can run it except under the most unusual case (then maybe the MA sends an error, maybe it does nothing). If the MA is offline, then I guess it can't send an error msg. where appropriate the Measurement Method will define the initial part to check whether the Peer has enough resources to run the test - this is handled similarly to the case where the MA detects that there's user traffic so shouldn't run the test. I guess resources could include battery life. I think probably the Method should define what to do - for example delay the test and re-try. =20 My view is that the MA should act autonomously - it gets instructed what test to run and when, then it gets on with it. Negotiation back and forth would add a lot to the complexity and personally I don't see much gain - this is supposed to be something simple to do. =20 =20 My assumption here - the operator of the measurement system checks in the lab what Methods can run on which of its types of MAs - it allows some margin for error - it definitely doesn't try and operate Methods which will run ok sometimes and not at other times (when the device containing the MA is "busy"). When my ISP asks my mobile device to perform some hourly test, how do they know it has enough battery to last? How can they know whether the device will be connected each hour? How can they predict the CPU and memory status at test time? If the Result isn't collected or is suspected of being wrong for some reason, then it's marked when the Results are reported. I agree in some circumstances the measurement system may want to tell the Controller (the feedback loop out of scope of lmap to define) Good. P. =20 Thanks Phil =20 From: Paul Aitken [mailto:paitken@cisco.com]=20 Sent: 05 September 2013 12:16 To: Eardley,PL,Philip,TUB8 R Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller =20 Phil, A controller can't forget what an MA can do unless / untll it first knows... so presumably there's a discovery phase where a (new) controller becomes aware of which MAs are within its control, and what the capabilities of each MA are. This has to be a dynamic process so new MAs can appear (and disappear) at any time. Whether the controller discovers MAs, or the MAs announce themselves to the controller depends on the protocol, firewalls, etc. See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8 After this there are a couple of failure scenarios: * Immediate: the controller requests an MA perform a test; the MA knows it's not capable of performing that test (eg due to a conflict or lack of resources). The MA can immediately indicate an error code to the controller. The controller could request a different test or choose a different MA. * Future: the controller requests an MA perform a test in the future (eg, at midnight), or a repeating test (eg, hourly). The MA accepts the test, indicating OK to the controller. Later the MA later discovers that it's not capable of performing the test. Depending on the control protocol, there may or may not be a connection between the MA and the controller. So the MA may have to indicate an error to the collector - especially if it wants to report partial results for an incomplete repeating test. If the MA indicates the error to the collector, does the collector need to tell the controller that the test didn't happen, or only partially happened? Aamer and I supposed so, which is why we added the controller / collector feedback loop. OTOH, if the controller doesn't need to know that the test(s) didn't happen, then why do we need error codes at all? The controller tells an MA to perform the test, and either it does or doesn't... it doesn't make sense, right? P. Another issue: There is no negotiation between the MA and Controller - the Controller simply sends the Instruction to the MA, with the details of the Measurement Tasks to perform.=20 In general we expect that the measurement system understands the capabilities of its MAs (probably there are only one or a few classes of MA), so negotiation about the MA's capabilities would have little benefit. It would also add complexity to the MA, Controller and Control Protocol.=20 =20 It is possible that the MA can't perform the requested Measurement Task. So the Control Protocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to send a list of all the Measurement Methods that it is capable of, in case 'something goes wrong' and the Controller forgets what the MA can do. Comment: this idea hasn't had much discussion yet, but appears in the Information Model i-d =20 Thoughts?=20 Thanks phil =09 =09 =09 =09 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap =20 =20 ------_=_NextPart_001_01CEAA6B.2469B400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems that there = are major questions on USE cases. Whether it is Discovery/Registration, = Bootstrapped or self contained, finding MA capabilities, Test is MA initiated or = Controller initiated, to who and how to report the results, what test authorization = or CAC accomplishes,  would be best to agree on a set of use cases and = then apply the details.

 

Sharam

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: Thursday, September 05, 2013 10:04 AM
To: paitken@cisco.com
Cc: lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation = between MA and Controller

 

Couple of comments inline

thanks

phil

 

From: Paul Aitken = [mailto:paitken@cisco.com]
Sent: 05 September 2013 14:33
To: Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation = between MA and Controller

 

Phil,

I don’t think lmap should define a dynamic MA = discovery protocol


If I buy a new router or STB, or if I install an app on my mobile = device, how is the controller to know that new MAs are available in the network?

If the mobile device moves to a different network, how is the controller = to know? The device might even move from one controller to another.

[phil] yes, something needs to handle this. I’m = suggesting this is access/device type specific – eg BBF protocol for a = broadband forum device, eg an app you download to your mobile etc. so not an lmap feature.

On your “Future” bullet – = << Later the MA later discovers that it's not capable of = performing the test>>

I was assuming that the MA understands what Measurement = Methods it can do, so it should know at the time when it gets the Instruction = whether it can do the test or not. So I’m not that worried about the MA later realising it can’t.


This is not so easily dismissed, since there are many reasons that the = MA may be able to accept the test at request time, but quite unable to run it = at a later test time. eg, the MA may be resource bound, offline, or not be = able to obtain resources from a test peer - none of which it knows at request = time unless the test is immediate.

[phil] I think it’s a bad idea to try and cope with = the MA sometimes lacking CPU etc resources to run a test. The test should be = designed and checked in the lab such that the MA can run it except under the most unusual case (then maybe the MA sends an error, maybe it does nothing). = If the MA is offline, then I guess it can’t send an error msg. where = appropriate the Measurement Method will define the initial part to check whether the = Peer has enough resources to run the test – this is handled similarly = to the case where the MA detects that there’s user traffic so = shouldn’t run the test. I guess resources could include battery life. I think = probably the Method should define what to do – for example delay the test = and re-try.

 

My view is that the MA should act autonomously – it = gets instructed what test to run and when, then it gets on with it. = Negotiation back and forth would add a lot to the complexity and personally I don’t = see much gain – this is supposed to be something simple to = do.

 

 

My assumption here – the operator of the measurement = system checks in the lab what Methods can run on which of its types of MAs = – it allows some margin for error – it definitely doesn’t try and operate Methods which will run ok sometimes and not at other times (when = the device containing the MA is “busy”).


When my ISP asks my mobile device to perform some hourly test, how do = they know it has enough battery to last? How can they know whether the device will = be connected each hour? How can they predict the CPU and memory status at = test time?


If the Result isn’t collected or is suspected of being = wrong for some reason, then it’s marked when the Results are reported. I = agree in some circumstances the measurement system may want to tell the = Controller (the feedback loop out of scope of lmap to define)


Good.

P.

 

Thanks

Phil

 

From: Paul Aitken [mailto:paitken@cisco.com]
Sent: 05 September 2013 12:16
To: Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation = between MA and Controller

 

Phil,

A controller can't forget what an MA can do unless / untll it first = knows... so presumably there's a discovery phase where a (new) controller becomes = aware of which MAs are within its control, and what the capabilities of each MA = are. This has to be a dynamic process so new MAs can appear (and disappear) = at any time. Whether the controller discovers MAs, or the MAs announce = themselves to the controller depends on the protocol, firewalls, etc.

See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3= .8


After this there are a couple of failure scenarios:

* Immediate: the controller requests an MA perform a test; the MA knows = it's not capable of performing that test (eg due to a conflict or lack of resources). The MA can immediately indicate an error code to the = controller. The controller could request a different test or choose a different = MA.

* Future: the controller requests an MA perform a test in the future = (eg, at midnight), or a repeating test (eg, hourly). The MA accepts the test, indicating OK to the controller. Later the MA later discovers that it's = not capable of performing the test. Depending on the control protocol, there = may or may not be a connection between the MA and the controller. So the MA may = have to indicate an error to the collector - especially if it wants to report partial results for an incomplete repeating test.

If the MA indicates the error to the collector, does the collector need = to tell the controller that the test didn't happen, or only partially happened? = Aamer and I supposed so, which is why we added the controller / collector = feedback loop. OTOH, if the controller doesn't need to know that the test(s) = didn't happen, then why do we need error codes at all? The controller tells an = MA to perform the test, and either it does or doesn't... it doesn't make = sense, right?

P.

Another issue:

There is no negotiation between the MA and Controller - the Controller simply = sends the Instruction to the MA, with the details of the Measurement Tasks to perform.

In general we expect that the measurement system understands the = capabilities of its MAs (probably there are only one or a few classes of MA), so = negotiation about the MA’s capabilities would have little benefit. It would = also add complexity to the MA, Controller and Control Protocol.

 

It is possible that the MA can’t perform the requested Measurement = Task. So the Control Protocol needs to allow the MA to reply with an error code. = It has also been suggested that the Controller should be able to ask the MA to = send a list of all the Measurement Methods that it is capable of, in case = ‘something goes wrong’ and the Controller forgets what the MA can do. = Comment: this idea hasn’t had much discussion yet, but appears in the = Information Model i-d

 

Thoughts?

Thanks

phil




_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/= mailman/listinfo/lmap

 

 

------_=_NextPart_001_01CEAA6B.2469B400-- From marcelo@it.uc3m.es Fri Sep 6 00:06:10 2013 Return-Path: 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 8E07E11E8255 for ; Fri, 6 Sep 2013 00:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 MFMxPi15+mQT for ; Fri, 6 Sep 2013 00:06:05 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 136CB11E8174 for ; Fri, 6 Sep 2013 00:06:01 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 667CC11BCF44 for ; Fri, 6 Sep 2013 09:05:40 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost19.it.uc3m.es (dummyhost27.it.uc3m.es [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 446F09D25F8 for ; Fri, 6 Sep 2013 09:05:40 +0200 (CEST) Message-ID: <52297EC3.8010708@it.uc3m.es> Date: Fri, 06 Sep 2013 09:05:39 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lmap@ietf.org References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Fri, 06 Sep 2013 09:05:40 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20130.005 X-TM-AS-Result: No--24.240-7.0-31-1 X-imss-scan-details: No--24.240-7.0-31-1 Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 07:06:10 -0000 So, let me expand on Barbara's list and tweak it a bit. I think we need to following functionalities: - A mechanism for MA discovery i.e. to find out which MA's are out there. I think this is part of the Bootstrap or configuration phase. - A mechanism for MA capabilities advertisement. i.e. assuming that the Controller knows what are the MAs out there, a mechanism to find out which are the capabilties of each MA i.e. what tests it supports. - A mechanism to find out if the instructions that the controller have sent to the MA have been executed succesfully and if not, what is the reason they were not. I think the framework and the information model shoudl cover all these. I think the WG should prioritize which items to focus on at the begining. Makes sense? El 05/09/13 15:57, STARK, BARBARA H escribió: > Not sure which email in this thread to start from, so I just cleaned out all other text... > > Advertisement: > This is a really simple thing to do, and any good control protocol with a well-designed data model should be perfectly capable of this. It is not part of bootstrap. > For example, if TR-069 were being used as the control protocol (and, yes, I'm talking about Control and not bootstrap), there would be an xml parameter that lists capabilities, as well as xml parameters that match up to the enabling/disabling/execution of these capabilities, and setting of specific parameters associated with these capabilities. Via this exemplary TR-069 interface, the Controller can request the MA tell the Controller (1) the entire data model structure (every single xml parameter) and (2) the current values of these xml parameters (e.g., the current value of a capability list xml parameter). It's not necessary to get this info every time. Important changes can be "evented", so the Controller is informed either that changes have occurred, and even what changes have occurred. > > IMO, lmap should not recommend a protocol that isn't capable of such incredibly basic functionality. > > Negotiation: > I don't know that I would call it a negotiation as much as the MA having proper ways to tell the Controller "No". Again, using TR-069 as an example, if the Controller tells the MA to set xml parameters that the MA doesn't have in its TR-069 data model, then the MA can say "No, I don't have those parameters." If the Controller tells the MA to set xml parameters that have been locked so they cannot be written to, then the MA tells the Controller "No, those are locked". If there is some temporary reason the MA can't comply, then the MA needs to tell the Controller "No, not right now". > > Similarly, if a test were scheduled to be run by the Controller, and the MA doesn't run it for some reason, there should be an xml parameter that gives the reason why the test wasn't run (a status or result parameter). The allowed values defined for this parameter need to provide the necessary level of information to the Controller. When the Controller reads the value of that parameter, it gets the info it needs. > > Since I know that TR-069 can easily do advertisement and negotiation with a well-designed data model (and, yes, in TR-069 this level of communication is done through data model parameters and their values and not through specific/different RPCs or RPC error messages), I'm not understanding why there's debate about whether or not these should be criteria in Control protocol selection and requirements when doing that protocol's data model design. IMO, of course they're required. > Barbara > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > From j.schoenwaelder@jacobs-university.de Fri Sep 6 01:02:21 2013 Return-Path: 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 1B16511E80C5 for ; Fri, 6 Sep 2013 01:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 yw9OShz84Oop for ; Fri, 6 Sep 2013 01:02:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A7EE521F8FB4 for ; Fri, 6 Sep 2013 01:02:12 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C08820C62; Fri, 6 Sep 2013 10:02:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yt8wZzqzmY3m; Fri, 6 Sep 2013 10:02:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC6F420C74; Fri, 6 Sep 2013 10:02:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D5ACA28385BB; Fri, 6 Sep 2013 10:02:02 +0200 (CEST) Date: Fri, 6 Sep 2013 10:02:02 +0200 From: Juergen Schoenwaelder To: marcelo bagnulo braun Message-ID: <20130906080202.GC60308@elstar.local> Mail-Followup-To: marcelo bagnulo braun , lmap@ietf.org References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> <52297EC3.8010708@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52297EC3.8010708@it.uc3m.es> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 08:02:21 -0000 On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun wrote: > So, let me expand on Barbara's list and tweak it a bit. > > I think we need to following functionalities: > > - A mechanism for MA discovery i.e. to find out which MA's are out > there. I think this is part of the Bootstrap or configuration phase. > > - A mechanism for MA capabilities advertisement. i.e. assuming that > the Controller knows what are the MAs out there, a mechanism to find > out which are the capabilties of each MA i.e. what tests it > supports. > > - A mechanism to find out if the instructions that the controller > have sent to the MA have been executed succesfully and if not, what > is the reason they were not. > > I think the framework and the information model shoudl cover all these. > I think the WG should prioritize which items to focus on at the begining. > > Makes sense? I am not sure about a generic discovery mechanism. The general framework assumes that the bootstrapping mechanism provides MA with sufficient information that they can contact they initial controller. How that is done is bootstrap mechanism specific. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From marcelo@it.uc3m.es Fri Sep 6 05:42:26 2013 Return-Path: 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 2522621E80CA for ; Fri, 6 Sep 2013 05:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 EfoXT2SYCMwd for ; Fri, 6 Sep 2013 05:42:20 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 32EFA21E80B5 for ; Fri, 6 Sep 2013 05:42:20 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4DFAE8948A3 for ; Fri, 6 Sep 2013 14:42:18 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost19.it.uc3m.es (unknown [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 409B676B3C8 for ; Fri, 6 Sep 2013 14:42:18 +0200 (CEST) Message-ID: <5229CDA9.5030207@it.uc3m.es> Date: Fri, 06 Sep 2013 14:42:17 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lmap@ietf.org References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> <52297EC3.8010708@it.uc3m.es> <20130906080202.GC60308@elstar.local> In-Reply-To: <20130906080202.GC60308@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Fri, 06 Sep 2013 14:42:18 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20130.007 X-TM-AS-Result: No--13.873-7.0-31-1 X-imss-scan-details: No--13.873-7.0-31-1 Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 12:42:26 -0000 El 06/09/13 10:02, Juergen Schoenwaelder escribió: > On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun wrote: >> So, let me expand on Barbara's list and tweak it a bit. >> >> I think we need to following functionalities: >> >> - A mechanism for MA discovery i.e. to find out which MA's are out >> there. I think this is part of the Bootstrap or configuration phase. >> >> - A mechanism for MA capabilities advertisement. i.e. assuming that >> the Controller knows what are the MAs out there, a mechanism to find >> out which are the capabilties of each MA i.e. what tests it >> supports. >> >> - A mechanism to find out if the instructions that the controller >> have sent to the MA have been executed succesfully and if not, what >> is the reason they were not. >> >> I think the framework and the information model shoudl cover all these. >> I think the WG should prioritize which items to focus on at the begining. >> >> Makes sense? > I am not sure about a generic discovery mechanism. The general > framework assumes that the bootstrapping mechanism provides MA with > sufficient information that they can contact they initial controller. > How that is done is bootstrap mechanism specific. Right, and that is one discovery mechanism, isn't it? Regards, marcelo > > /js > From j.schoenwaelder@jacobs-university.de Fri Sep 6 06:43:11 2013 Return-Path: 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 7EE0B11E82A6 for ; Fri, 6 Sep 2013 06:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.195 X-Spam-Level: X-Spam-Status: No, score=-103.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 dDYyVpDVVcRn for ; Fri, 6 Sep 2013 06:43:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 44A3211E8128 for ; Fri, 6 Sep 2013 06:43:06 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC4C620C88; Fri, 6 Sep 2013 15:43:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Q-DARM8vb_qI; Fri, 6 Sep 2013 15:43:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39F2620C78; Fri, 6 Sep 2013 15:43:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A6803283908E; Fri, 6 Sep 2013 15:42:57 +0200 (CEST) Date: Fri, 6 Sep 2013 15:42:56 +0200 From: Juergen Schoenwaelder To: marcelo bagnulo braun Message-ID: <20130906134256.GC60998@elstar.local> Mail-Followup-To: marcelo bagnulo braun , lmap@ietf.org References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> <52297EC3.8010708@it.uc3m.es> <20130906080202.GC60308@elstar.local> <5229CDA9.5030207@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5229CDA9.5030207@it.uc3m.es> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 13:43:11 -0000 On Fri, Sep 06, 2013 at 02:42:17PM +0200, marcelo bagnulo braun wrote: > El 06/09/13 10:02, Juergen Schoenwaelder escribió: > >On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun wrote: > >>So, let me expand on Barbara's list and tweak it a bit. > >> > >>I think we need to following functionalities: > >> > >>- A mechanism for MA discovery i.e. to find out which MA's are out > >>there. I think this is part of the Bootstrap or configuration phase. > >> > >>- A mechanism for MA capabilities advertisement. i.e. assuming that > >>the Controller knows what are the MAs out there, a mechanism to find > >>out which are the capabilties of each MA i.e. what tests it > >>supports. > >> > >>- A mechanism to find out if the instructions that the controller > >>have sent to the MA have been executed succesfully and if not, what > >>is the reason they were not. > >> > >>I think the framework and the information model shoudl cover all these. > >>I think the WG should prioritize which items to focus on at the begining. > >> > >>Makes sense? > >I am not sure about a generic discovery mechanism. The general > >framework assumes that the bootstrapping mechanism provides MA with > >sufficient information that they can contact they initial controller. > >How that is done is bootstrap mechanism specific. > > Right, and that is one discovery mechanism, isn't it? > No, not for me. There will be several different boot strapping mechanisms. Some of them may involve a specific LMAP discovery phase, others already have a suitable discovery phase and yet others may not need a discovery phase. Hence, the general framework and information model should be silent about this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From sharam.hakimi@exfo.com Fri Sep 6 06:44:04 2013 Return-Path: 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 3CBBE11E818B for ; Fri, 6 Sep 2013 06:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] 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 dJVtq2oFKx1n for ; Fri, 6 Sep 2013 06:44:00 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id F284F11E8128 for ; Fri, 6 Sep 2013 06:43:59 -0700 (PDT) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Sep 2013 09:43:59 -0400 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Sep 2013 09:43:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Sep 2013 09:36:47 -0400 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02804627@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: Ac6q/ozeP1VKjSmdRa+dow6uEfH+FwABt0Ew References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch><2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com><52297EC3.8010708@it.uc3m.es> <20130906080202.GC60308@elstar.local> <5229CDA9.5030207@it.uc3m.es> From: "Sharam Hakimi" To: "marcelo bagnulo braun" , X-OriginalArrivalTime: 06 Sep 2013 13:43:58.0509 (UTC) FILETIME=[2343CDD0:01CEAB07] Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 13:44:04 -0000 I would call that Registration. I guess it is Discovery depending who's = point of view one looks at it. If it from the point of view of the MA, = it is Discovery and if it is from the point of view of the Controller, = it is registration. For the case of an MA where it is behind a NAT, it would have to be = Registration because discovery from a Controller would not be possible. Sharam -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of = marcelo bagnulo braun Sent: Friday, September 06, 2013 8:42 AM To: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA = and Controller El 06/09/13 10:02, Juergen Schoenwaelder escribi=F3: > On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun wrote: >> So, let me expand on Barbara's list and tweak it a bit. >> >> I think we need to following functionalities: >> >> - A mechanism for MA discovery i.e. to find out which MA's are out >> there. I think this is part of the Bootstrap or configuration phase. >> >> - A mechanism for MA capabilities advertisement. i.e. assuming that >> the Controller knows what are the MAs out there, a mechanism to find >> out which are the capabilties of each MA i.e. what tests it >> supports. >> >> - A mechanism to find out if the instructions that the controller >> have sent to the MA have been executed succesfully and if not, what >> is the reason they were not. >> >> I think the framework and the information model shoudl cover all = these. >> I think the WG should prioritize which items to focus on at the = begining. >> >> Makes sense? > I am not sure about a generic discovery mechanism. The general > framework assumes that the bootstrapping mechanism provides MA with > sufficient information that they can contact they initial controller. > How that is done is bootstrap mechanism specific. Right, and that is one discovery mechanism, isn't it? Regards, marcelo > > /js > _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From j.schoenwaelder@jacobs-university.de Fri Sep 6 06:55:30 2013 Return-Path: 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 9821521E80F3 for ; Fri, 6 Sep 2013 06:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 qKW4p5KRfx4B for ; Fri, 6 Sep 2013 06:55:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C8BF121E80C0 for ; Fri, 6 Sep 2013 06:55:25 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3818920C8F; Fri, 6 Sep 2013 15:55:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aiEzuu48tZu0; Fri, 6 Sep 2013 15:55:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8A0020C79; Fri, 6 Sep 2013 15:55:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 371C728391AE; Fri, 6 Sep 2013 15:55:18 +0200 (CEST) Date: Fri, 6 Sep 2013 15:55:18 +0200 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20130906135518.GE60998@elstar.local> Mail-Followup-To: Sharam Hakimi , marcelo bagnulo braun , lmap@ietf.org References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> <52297EC3.8010708@it.uc3m.es> <20130906080202.GC60308@elstar.local> <5229CDA9.5030207@it.uc3m.es> <084CDC75FEC1E640B60338273BEACDFA02804627@spboexc01.exfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02804627@spboexc01.exfo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcelo bagnulo braun , lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 13:55:31 -0000 Sharam, the MA, once bootstrapped, registers with the controller. I think this is all well described. My point was that any discovery of MAs is part of a bootstrapping mechanism, not part of the LMAP framework itsef. /js On Fri, Sep 06, 2013 at 09:36:47AM -0400, Sharam Hakimi wrote: > > I would call that Registration. I guess it is Discovery depending who's point of view one looks at it. If it from the point of view of the MA, it is Discovery and if it is from the point of view of the Controller, it is registration. > > For the case of an MA where it is behind a NAT, it would have to be Registration because discovery from a Controller would not be possible. > > Sharam > > > > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Friday, September 06, 2013 8:42 AM > To: lmap@ietf.org > Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller > > El 06/09/13 10:02, Juergen Schoenwaelder escribió: > > On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun wrote: > >> So, let me expand on Barbara's list and tweak it a bit. > >> > >> I think we need to following functionalities: > >> > >> - A mechanism for MA discovery i.e. to find out which MA's are out > >> there. I think this is part of the Bootstrap or configuration phase. > >> > >> - A mechanism for MA capabilities advertisement. i.e. assuming that > >> the Controller knows what are the MAs out there, a mechanism to find > >> out which are the capabilties of each MA i.e. what tests it > >> supports. > >> > >> - A mechanism to find out if the instructions that the controller > >> have sent to the MA have been executed succesfully and if not, what > >> is the reason they were not. > >> > >> I think the framework and the information model shoudl cover all these. > >> I think the WG should prioritize which items to focus on at the begining. > >> > >> Makes sense? > > I am not sure about a generic discovery mechanism. The general > > framework assumes that the bootstrapping mechanism provides MA with > > sufficient information that they can contact they initial controller. > > How that is done is bootstrap mechanism specific. > > Right, and that is one discovery mechanism, isn't it? > > Regards, marcelo > > > > > > /js > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Michael.K.Bugenhagen@centurylink.com Fri Sep 6 08:06:09 2013 Return-Path: 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 D35A711E81A4 for ; Fri, 6 Sep 2013 08:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 xGseWa2Nmk-Q for ; Fri, 6 Sep 2013 08:06:04 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id D305F11E81A5 for ; Fri, 6 Sep 2013 08:05:59 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r86F5lAh000183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Sep 2013 09:05:48 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 47EE31E0035; Fri, 6 Sep 2013 09:05:42 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 368721E0071; Fri, 6 Sep 2013 09:05:42 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r86F5fbL013179; Fri, 6 Sep 2013 09:05:41 -0600 (MDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r86F5f8I013173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 09:05:41 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.02.0318.001; Fri, 6 Sep 2013 10:05:41 -0500 From: "Bugenhagen, Michael K" To: "'marcelo bagnulo braun'" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: AQHOqjPGxJ8G+5lir0OtLdLMMxyTYpm3fzMAgAEfM4CAAA/BAIAATk2A///SJ+A= Date: Fri, 6 Sep 2013 15:05:40 +0000 Message-ID: References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> <52297EC3.8010708@it.uc3m.es> <20130906080202.GC60308@elstar.local> <5229CDA9.5030207@it.uc3m.es> In-Reply-To: <5229CDA9.5030207@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 15:06:10 -0000 I don't think Discovery the right term (we may be over extending it's defin= ition)... For what's being discussed .. Audit / Registration of capabilities is more = correct IMHO... Bigger picture -- there are two distinct steps IMHO=20 1) Discovery =3D Identification & authentication 2) Capability registration / resolution =3D Investigation of capabilities, = or registering of capabilities. Implementation wise (triggers and audit functions in the MA & controller) I used audit vs. registration of capabilities because as some else mentione= d a MA has a life cycle where it's functionality could change. To that end triggers need to be developed to 1) Drive a MA to re-register.... 2) An Audit function needs to be placed (sub command loop)in the controlle= r to ask the "MA" what it's capabilities are when the controller starts ge= tting failed or rejected tests... ie. A trigger event to scheduling testin= g to cause an audit.. Most of this is mom and apple pie for split control schemas so it shouldn'= t be a big leap. Regards, Mike -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of mar= celo bagnulo braun Sent: Friday, September 06, 2013 7:42 AM To: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and C= ontroller El 06/09/13 10:02, Juergen Schoenwaelder escribi=F3: > On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun wrote: >> So, let me expand on Barbara's list and tweak it a bit. >> >> I think we need to following functionalities: >> >> - A mechanism for MA discovery i.e. to find out which MA's are out=20 >> there. I think this is part of the Bootstrap or configuration phase. >> >> - A mechanism for MA capabilities advertisement. i.e. assuming that=20 >> the Controller knows what are the MAs out there, a mechanism to find=20 >> out which are the capabilties of each MA i.e. what tests it supports. >> >> - A mechanism to find out if the instructions that the controller=20 >> have sent to the MA have been executed succesfully and if not, what=20 >> is the reason they were not. >> >> I think the framework and the information model shoudl cover all these. >> I think the WG should prioritize which items to focus on at the begining= . >> >> Makes sense? > I am not sure about a generic discovery mechanism. The general=20 > framework assumes that the bootstrapping mechanism provides MA with=20 > sufficient information that they can contact they initial controller. > How that is done is bootstrap mechanism specific. Right, and that is one discovery mechanism, isn't it? Regards, marcelo > > /js > _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From sharam.hakimi@exfo.com Fri Sep 6 09:03:36 2013 Return-Path: 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 D998221F9C22 for ; Fri, 6 Sep 2013 09:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 GXpON5WTYwH1 for ; Fri, 6 Sep 2013 09:03:32 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44B21F893E for ; Fri, 6 Sep 2013 09:03:31 -0700 (PDT) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Sep 2013 12:03:19 -0400 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Sep 2013 12:03:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Sep 2013 12:02:17 -0400 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02804677@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: Ac6rCL3nfGbj3iQcTQialuq1J0ahEQAEATpA References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> <52297EC3.8010708@it.uc3m.es> <20130906080202.GC60308@elstar.local> <5229CDA9.5030207@it.uc3m.es> <084CDC75FEC1E640B60338273BEACDFA02804627@spboexc01.exfo.com> <20130906135518.GE60998@elstar.local> From: "Sharam Hakimi" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 06 Sep 2013 16:03:18.0870 (UTC) FILETIME=[9A6DA760:01CEAB1A] Cc: marcelo bagnulo braun , lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 16:03:37 -0000 Juergen, I think Discovery or registration is part of bootstrapping. The MA would = have to be known by the controller in order to be able to download a = version or the latest version of what the MA needs to run.=20 I would say that the device would be registered at that point. Sharam =20 -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, September 06, 2013 9:55 AM To: Sharam Hakimi Cc: marcelo bagnulo braun; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA = and Controller Sharam, the MA, once bootstrapped, registers with the controller. I think this is all well described. My point was that any discovery of MAs is part of a bootstrapping mechanism, not part of the LMAP framework itsef. /js On Fri, Sep 06, 2013 at 09:36:47AM -0400, Sharam Hakimi wrote: >=20 > I would call that Registration. I guess it is Discovery depending = who's point of view one looks at it. If it from the point of view of the = MA, it is Discovery and if it is from the point of view of the = Controller, it is registration. >=20 > For the case of an MA where it is behind a NAT, it would have to be = Registration because discovery from a Controller would not be possible. >=20 > Sharam >=20 >=20 >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of marcelo bagnulo braun > Sent: Friday, September 06, 2013 8:42 AM > To: lmap@ietf.org > Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA = and Controller >=20 > El 06/09/13 10:02, Juergen Schoenwaelder escribi=F3: > > On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun = wrote: > >> So, let me expand on Barbara's list and tweak it a bit. > >> > >> I think we need to following functionalities: > >> > >> - A mechanism for MA discovery i.e. to find out which MA's are out > >> there. I think this is part of the Bootstrap or configuration = phase. > >> > >> - A mechanism for MA capabilities advertisement. i.e. assuming that > >> the Controller knows what are the MAs out there, a mechanism to = find > >> out which are the capabilties of each MA i.e. what tests it > >> supports. > >> > >> - A mechanism to find out if the instructions that the controller > >> have sent to the MA have been executed succesfully and if not, what > >> is the reason they were not. > >> > >> I think the framework and the information model shoudl cover all = these. > >> I think the WG should prioritize which items to focus on at the = begining. > >> > >> Makes sense? > > I am not sure about a generic discovery mechanism. The general > > framework assumes that the bootstrapping mechanism provides MA with > > sufficient information that they can contact they initial = controller. > > How that is done is bootstrap mechanism specific. >=20 > Right, and that is one discovery mechanism, isn't it? >=20 > Regards, marcelo >=20 >=20 > > > > /js > > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Sep 6 09:41:22 2013 Return-Path: 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 272A011E81A0 for ; Fri, 6 Sep 2013 09:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 FOo+3ujIYPb9 for ; Fri, 6 Sep 2013 09:41:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 64BD111E8199 for ; Fri, 6 Sep 2013 09:41:17 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 522A520C83; Fri, 6 Sep 2013 18:41:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id du-T607B8rMt; Fri, 6 Sep 2013 18:41:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9D2B20C7F; Fri, 6 Sep 2013 18:41:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5C0DD28396BE; Fri, 6 Sep 2013 18:41:07 +0200 (CEST) Date: Fri, 6 Sep 2013 18:41:07 +0200 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20130906164105.GA61929@elstar.local> Mail-Followup-To: Sharam Hakimi , marcelo bagnulo braun , lmap@ietf.org References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> <52297EC3.8010708@it.uc3m.es> <20130906080202.GC60308@elstar.local> <5229CDA9.5030207@it.uc3m.es> <084CDC75FEC1E640B60338273BEACDFA02804627@spboexc01.exfo.com> <20130906135518.GE60998@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02804677@spboexc01.exfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02804677@spboexc01.exfo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcelo bagnulo braun , lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 16:41:22 -0000 Sharam, I think the model is that the device bootstraps, it then registers by connecting to the initial controller, then the controller does what it needs to do. The bootstrapping phase may involve discovery of MAs such that they can be subsequently bootstrapped but this is bootstrap method specific and as far as I understand the charter bootstrapping is out of scope for LMAP 1.0. Hence, from the charter perspective, our work begins when the MA has all the needed information to initiate a connection to the initial controller. This is my view as long as we talk about "MA discovery". The thread originally started from "capability discovery". Trevor's information model draft talks about this as part of so called Status Information: 5. Status Information. Information on the general status and capabilities of the MA. For example, the set of measurements that are supported on the device Some further details are in section 2.6 of draft-burbridge-lmap-information-model-00.txt. How this information is made available to the Controller depends on the protocol being used. One option is that this information is pushed to the Controller while registering and MAs have to re-register when their capabilities change. There may be many other options - but what is a reasonable choice depends to some extend on the protocol being used for LMAP and hence can't fully answer this question at this point in time. Makes sense? /js On Fri, Sep 06, 2013 at 12:02:17PM -0400, Sharam Hakimi wrote: > Juergen, > > I think Discovery or registration is part of bootstrapping. The MA would have to be known by the controller in order to be able to download a version or the latest version of what the MA needs to run. > > I would say that the device would be registered at that point. > > Sharam > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, September 06, 2013 9:55 AM > To: Sharam Hakimi > Cc: marcelo bagnulo braun; lmap@ietf.org > Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller > > Sharam, > > the MA, once bootstrapped, registers with the controller. I think this > is all well described. My point was that any discovery of MAs is part > of a bootstrapping mechanism, not part of the LMAP framework itsef. > > /js > > On Fri, Sep 06, 2013 at 09:36:47AM -0400, Sharam Hakimi wrote: > > > > I would call that Registration. I guess it is Discovery depending who's point of view one looks at it. If it from the point of view of the MA, it is Discovery and if it is from the point of view of the Controller, it is registration. > > > > For the case of an MA where it is behind a NAT, it would have to be Registration because discovery from a Controller would not be possible. > > > > Sharam > > > > > > > > -----Original Message----- > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > > Sent: Friday, September 06, 2013 8:42 AM > > To: lmap@ietf.org > > Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller > > > > El 06/09/13 10:02, Juergen Schoenwaelder escribió: > > > On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun wrote: > > >> So, let me expand on Barbara's list and tweak it a bit. > > >> > > >> I think we need to following functionalities: > > >> > > >> - A mechanism for MA discovery i.e. to find out which MA's are out > > >> there. I think this is part of the Bootstrap or configuration phase. > > >> > > >> - A mechanism for MA capabilities advertisement. i.e. assuming that > > >> the Controller knows what are the MAs out there, a mechanism to find > > >> out which are the capabilties of each MA i.e. what tests it > > >> supports. > > >> > > >> - A mechanism to find out if the instructions that the controller > > >> have sent to the MA have been executed succesfully and if not, what > > >> is the reason they were not. > > >> > > >> I think the framework and the information model shoudl cover all these. > > >> I think the WG should prioritize which items to focus on at the begining. > > >> > > >> Makes sense? > > > I am not sure about a generic discovery mechanism. The general > > > framework assumes that the bootstrapping mechanism provides MA with > > > sufficient information that they can contact they initial controller. > > > How that is done is bootstrap mechanism specific. > > > > Right, and that is one discovery mechanism, isn't it? > > > > Regards, marcelo > > > > > > > > > > /js > > > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From sharam.hakimi@exfo.com Fri Sep 6 15:05:02 2013 Return-Path: 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 0FD4521E80ED for ; Fri, 6 Sep 2013 15:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 m42raNTIUvfJ for ; Fri, 6 Sep 2013 15:04:58 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 8687A21E80F1 for ; Fri, 6 Sep 2013 15:04:49 -0700 (PDT) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Sep 2013 18:04:48 -0400 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Sep 2013 18:04:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Sep 2013 17:56:50 -0400 Message-ID: <084CDC75FEC1E640B60338273BEACDFA028046DE@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: Ac6rH+lBufTru1yyRVuVVX+7QgnI7QAKVggw References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> <52297EC3.8010708@it.uc3m.es> <20130906080202.GC60308@elstar.local> <5229CDA9.5030207@it.uc3m.es> <084CDC75FEC1E640B60338273BEACDFA02804627@spboexc01.exfo.com> <20130906135518.GE60998@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02804677@spboexc01.exfo.com> <20130906164105.GA61929@elstar.local> From: "Sharam Hakimi" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 06 Sep 2013 22:04:48.0042 (UTC) FILETIME=[1A2EA8A0:01CEAB4D] Cc: marcelo bagnulo braun , lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 22:05:02 -0000 Juergen, Bootstrapping might not be needed in all cases and it will be individual = user defined per the model. After either coming up to the bootstrapping = point or coming up to the point that the MA can communicate from an = already initial setup, the MA would have to REGISTER with the controller = that it has been told to use. The discussion has been around MA = discovery and not MA capability discovery. I don't know how something = can be bootstrapped or DISCOVERED if it has not Registered. Thanks, Sharam -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, September 06, 2013 12:41 PM To: Sharam Hakimi Cc: marcelo bagnulo braun; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA = and Controller Sharam, I think the model is that the device bootstraps, it then registers by connecting to the initial controller, then the controller does what it needs to do. The bootstrapping phase may involve discovery of MAs such that they can be subsequently bootstrapped but this is bootstrap method specific and as far as I understand the charter bootstrapping is out of scope for LMAP 1.0. Hence, from the charter perspective, our work begins when the MA has all the needed information to initiate a connection to the initial controller. This is my view as long as we talk about "MA discovery". The thread originally started from "capability discovery". Trevor's information model draft talks about this as part of so called Status Information: 5. Status Information. Information on the general status and capabilities of the MA. For example, the set of measurements that are supported on the device Some further details are in section 2.6 of draft-burbridge-lmap-information-model-00.txt. How this information is made available to the Controller depends on the protocol being used. One option is that this information is pushed to the Controller while registering and MAs have to re-register when their capabilities change. There may be many other options - but what is a reasonable choice depends to some extend on the protocol being used for LMAP and hence can't fully answer this question at this point in time. Makes sense? /js On Fri, Sep 06, 2013 at 12:02:17PM -0400, Sharam Hakimi wrote: > Juergen, >=20 > I think Discovery or registration is part of bootstrapping. The MA = would have to be known by the controller in order to be able to download = a version or the latest version of what the MA needs to run.=20 >=20 > I would say that the device would be registered at that point. >=20 > Sharam > =20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Friday, September 06, 2013 9:55 AM > To: Sharam Hakimi > Cc: marcelo bagnulo braun; lmap@ietf.org > Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA = and Controller >=20 > Sharam, >=20 > the MA, once bootstrapped, registers with the controller. I think this > is all well described. My point was that any discovery of MAs is part > of a bootstrapping mechanism, not part of the LMAP framework itsef. >=20 > /js >=20 > On Fri, Sep 06, 2013 at 09:36:47AM -0400, Sharam Hakimi wrote: > >=20 > > I would call that Registration. I guess it is Discovery depending = who's point of view one looks at it. If it from the point of view of the = MA, it is Discovery and if it is from the point of view of the = Controller, it is registration. > >=20 > > For the case of an MA where it is behind a NAT, it would have to be = Registration because discovery from a Controller would not be possible. > >=20 > > Sharam > >=20 > >=20 > >=20 > > -----Original Message----- > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of marcelo bagnulo braun > > Sent: Friday, September 06, 2013 8:42 AM > > To: lmap@ietf.org > > Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between = MA and Controller > >=20 > > El 06/09/13 10:02, Juergen Schoenwaelder escribi=F3: > > > On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun = wrote: > > >> So, let me expand on Barbara's list and tweak it a bit. > > >> > > >> I think we need to following functionalities: > > >> > > >> - A mechanism for MA discovery i.e. to find out which MA's are = out > > >> there. I think this is part of the Bootstrap or configuration = phase. > > >> > > >> - A mechanism for MA capabilities advertisement. i.e. assuming = that > > >> the Controller knows what are the MAs out there, a mechanism to = find > > >> out which are the capabilties of each MA i.e. what tests it > > >> supports. > > >> > > >> - A mechanism to find out if the instructions that the controller > > >> have sent to the MA have been executed succesfully and if not, = what > > >> is the reason they were not. > > >> > > >> I think the framework and the information model shoudl cover all = these. > > >> I think the WG should prioritize which items to focus on at the = begining. > > >> > > >> Makes sense? > > > I am not sure about a generic discovery mechanism. The general > > > framework assumes that the bootstrapping mechanism provides MA = with > > > sufficient information that they can contact they initial = controller. > > > How that is done is bootstrap mechanism specific. > >=20 > > Right, and that is one discovery mechanism, isn't it? > >=20 > > Regards, marcelo > >=20 > >=20 > > > > > > /js > > > > >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Sep 6 23:39:03 2013 Return-Path: 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 16ECC21F9B4B for ; Fri, 6 Sep 2013 23:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Of2Kz7bGhESM for ; Fri, 6 Sep 2013 23:38:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC1221F9AAE for ; Fri, 6 Sep 2013 23:38:58 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 777F720C89; Sat, 7 Sep 2013 08:38:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vPlrS43emn0v; Sat, 7 Sep 2013 08:38:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C267220C41; Sat, 7 Sep 2013 08:38:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 91A44283A4CE; Sat, 7 Sep 2013 08:38:48 +0200 (CEST) Date: Sat, 7 Sep 2013 08:38:48 +0200 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20130907063848.GA64475@elstar.local> Mail-Followup-To: Sharam Hakimi , marcelo bagnulo braun , lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> <52297EC3.8010708@it.uc3m.es> <20130906080202.GC60308@elstar.local> <5229CDA9.5030207@it.uc3m.es> <084CDC75FEC1E640B60338273BEACDFA02804627@spboexc01.exfo.com> <20130906135518.GE60998@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02804677@spboexc01.exfo.com> <20130906164105.GA61929@elstar.local> <084CDC75FEC1E640B60338273BEACDFA028046DE@spboexc01.exfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA028046DE@spboexc01.exfo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcelo bagnulo braun , lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 06:39:03 -0000 Sharam, I think we are talking past each other. /js On Fri, Sep 06, 2013 at 05:56:50PM -0400, Sharam Hakimi wrote: > Juergen, > Bootstrapping might not be needed in all cases and it will be individual user defined per the model. After either coming up to the bootstrapping point or coming up to the point that the MA can communicate from an already initial setup, the MA would have to REGISTER with the controller that it has been told to use. The discussion has been around MA discovery and not MA capability discovery. I don't know how something can be bootstrapped or DISCOVERED if it has not Registered. > > > Thanks, > Sharam > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, September 06, 2013 12:41 PM > To: Sharam Hakimi > Cc: marcelo bagnulo braun; lmap@ietf.org > Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller > > Sharam, > > I think the model is that the device bootstraps, it then registers by > connecting to the initial controller, then the controller does what it > needs to do. The bootstrapping phase may involve discovery of MAs > such that they can be subsequently bootstrapped but this is bootstrap > method specific and as far as I understand the charter bootstrapping > is out of scope for LMAP 1.0. Hence, from the charter perspective, our > work begins when the MA has all the needed information to initiate a > connection to the initial controller. This is my view as long as we > talk about "MA discovery". > > The thread originally started from "capability discovery". Trevor's > information model draft talks about this as part of so called Status > Information: > > 5. Status Information. Information on the general status and > capabilities of the MA. For example, the set of measurements > that are supported on the device > > Some further details are in section 2.6 of > draft-burbridge-lmap-information-model-00.txt. How this information is > made available to the Controller depends on the protocol being > used. One option is that this information is pushed to the Controller > while registering and MAs have to re-register when their capabilities > change. There may be many other options - but what is a reasonable > choice depends to some extend on the protocol being used for LMAP > and hence can't fully answer this question at this point in time. > > Makes sense? > > /js > > On Fri, Sep 06, 2013 at 12:02:17PM -0400, Sharam Hakimi wrote: > > Juergen, > > > > I think Discovery or registration is part of bootstrapping. The MA would have to be known by the controller in order to be able to download a version or the latest version of what the MA needs to run. > > > > I would say that the device would be registered at that point. > > > > Sharam > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Friday, September 06, 2013 9:55 AM > > To: Sharam Hakimi > > Cc: marcelo bagnulo braun; lmap@ietf.org > > Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller > > > > Sharam, > > > > the MA, once bootstrapped, registers with the controller. I think this > > is all well described. My point was that any discovery of MAs is part > > of a bootstrapping mechanism, not part of the LMAP framework itsef. > > > > /js > > > > On Fri, Sep 06, 2013 at 09:36:47AM -0400, Sharam Hakimi wrote: > > > > > > I would call that Registration. I guess it is Discovery depending who's point of view one looks at it. If it from the point of view of the MA, it is Discovery and if it is from the point of view of the Controller, it is registration. > > > > > > For the case of an MA where it is behind a NAT, it would have to be Registration because discovery from a Controller would not be possible. > > > > > > Sharam > > > > > > > > > > > > -----Original Message----- > > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > > > Sent: Friday, September 06, 2013 8:42 AM > > > To: lmap@ietf.org > > > Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller > > > > > > El 06/09/13 10:02, Juergen Schoenwaelder escribió: > > > > On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun wrote: > > > >> So, let me expand on Barbara's list and tweak it a bit. > > > >> > > > >> I think we need to following functionalities: > > > >> > > > >> - A mechanism for MA discovery i.e. to find out which MA's are out > > > >> there. I think this is part of the Bootstrap or configuration phase. > > > >> > > > >> - A mechanism for MA capabilities advertisement. i.e. assuming that > > > >> the Controller knows what are the MAs out there, a mechanism to find > > > >> out which are the capabilties of each MA i.e. what tests it > > > >> supports. > > > >> > > > >> - A mechanism to find out if the instructions that the controller > > > >> have sent to the MA have been executed succesfully and if not, what > > > >> is the reason they were not. > > > >> > > > >> I think the framework and the information model shoudl cover all these. > > > >> I think the WG should prioritize which items to focus on at the begining. > > > >> > > > >> Makes sense? > > > > I am not sure about a generic discovery mechanism. The general > > > > framework assumes that the bootstrapping mechanism provides MA with > > > > sufficient information that they can contact they initial controller. > > > > How that is done is bootstrap mechanism specific. > > > > > > Right, and that is one discovery mechanism, isn't it? > > > > > > Regards, marcelo > > > > > > > > > > > > > > /js > > > > > > > > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Sep 10 06:20:04 2013 Return-Path: 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 F100111E816D for ; Tue, 10 Sep 2013 06:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_05=-1.11, USER_IN_WHITELIST=-100] 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 oRrfU5nMtEO2 for ; Tue, 10 Sep 2013 06:19:59 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5854721F997B for ; Tue, 10 Sep 2013 06:19:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEMACsbL1LGmAcV/2dsb2JhbABYA4JmIThLBq15lEKBIxZtB4IlAQEBAQMBAQEPCx00BBMCBAEIDQMBAwEBAQsUCSIMCxQHAQEFBQQTCBqHYAEGBZ4+hEecOhcEjyYLFh0LgwyBAAOZJYUnhWiFLYFjgT1yAYE3 X-IronPort-AV: E=Sophos;i="4.90,878,1371096000"; d="scan'208";a="27596225" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Sep 2013 09:19:58 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Sep 2013 09:17:45 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Tue, 10 Sep 2013 15:19:57 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements Thread-Index: AQHOrKqFA0K3v448rEew5z0nyotzsJm+9wXA Date: Tue, 10 Sep 2013 13:19:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128CEE9D@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 13:20:04 -0000 I am taking an exception from the usual policy of avoiding postings of suc= h announcements on the WG list for this workshop which seems to have relati= on to the scope of LMAP.=20 Regards, Dan =20 -----Original Message----- From: nmrg-bounces@irtf.org [mailto:nmrg-bounces@irtf.org] On Behalf Of Jue= rgen Schoenwaelder Sent: Sunday, September 08, 2013 6:46 PM To: nmrg@irtf.org Subject: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale networ= k measurements Call for Presentations 1st Workshop on Large Scale Network Measurements (31st NMRG meeting) Location: Zurich, Switzerland (co-located with CNSM 2013 [1]) Date: Monday, October 14 Deadline: Friday, September 20 Large-scale network measurement platforms have evolved during the past few = years. Some utilize specialized hardware probes (e.g., RIPE Atlas or SamKno= ws) while others utilize software probes that run on ordinary desktop compu= ters or smart phones (e.g., measurement projects related to M-Lab) or even = within Web browsers (e.g., Ookla Speedtest). This workshop aims at bringing together researchers and in particular PhD s= tudents working on topics such as: - novel metrics for measuring Internet performance - techniques to estimate quality of experience from raw measurements - novel data analysis techniques - interactive information visualization techniques - software and hardware tools - interfaces of measurement systems to network management systems We want the workshop to be an opportunity for attendees to exchange and dis= cuss their experiences and ideas. Presentations typically last around 20 mi= nutes (depending on the number of accepted presentations), followed by disc= ussion rounds. To propose a presentation, please send a short abstract (15 lines) to Juergen Schoenwaelder Jacobs University Bremen before September 20th, 2013. Please also contact us as soon as possible if = you want to attend the workshop without giving a presentation. The NMRG workshop is co-located with CNSM 2013 [1] but does not require a C= NSM registration. However, for organizational reasons, NMRG meeting attende= es are required to register with the contact provided above by September 20= th. This workshop is organized and sponsored by the EU projects Leone [2] and F= lamingo [3] in collaboration with the EU project mPlane [4]. For up-to-date= information, see [5]. [1] http://www.cnsm-conf.org/2013/ [2] http://www.leone-project.eu/ [3] http://www.fp7-flamingo.eu/ [4] http://www.ict-mplane.eu/ [5] http://tinyurl.com/pqfkd7e /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ nmrg mailing list nmrg@irtf.org https://www.irtf.org/mailman/listinfo/nmrg From acmorton@att.com Tue Sep 10 08:41:23 2013 Return-Path: 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 214EE21E813D for ; Tue, 10 Sep 2013 08:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Lz1L3xcz8Jwq for ; Tue, 10 Sep 2013 08:41:17 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id AB1A821E8053 for ; Tue, 10 Sep 2013 08:41:14 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 1D7641205AD; Tue, 10 Sep 2013 11:41:13 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (njfpsrvexg8.research.att.com [135.207.255.56]) by mail-blue.research.att.com (Postfix) with ESMTP id D6633F0393; Tue, 10 Sep 2013 11:41:13 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::a44a:8177:9a5d:ac00]) by njfpsrvexg8.research.att.com ([fe80::a44a:8177:9a5d:ac00%15]) with mapi; Tue, 10 Sep 2013 11:41:13 -0400 From: "MORTON, ALFRED C (AL)" To: "philip.eardley@bt.com" , "lmap@ietf.org" Date: Tue, 10 Sep 2013 11:41:12 -0400 Thread-Topic: LMAP framework issue #1 User-initiated Measurement Tasks Thread-Index: Ac6oxTl43dfkRXB1QZGOg/kNOKXELgFbsNxQ Message-ID: <2845723087023D4CB5114223779FA9C8A05B4DDF@njfpsrvexg8.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8A05B4DDFnjfpsrvexg8rese_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 15:41:23 -0000 --_000_2845723087023D4CB5114223779FA9C8A05B4DDFnjfpsrvexg8rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In what we now call case 2, the user-deployed measurement system: Phil wrote: ... There are at least two ways user-initiation could happen, in outline * a user could deploy their own measurement system, with their own MA, Cont= roller and Collector (possibly with all three functions in the same box). The user may also want= to report Measurement Results to a third party. One possible situation is that the ho= me contains a user-controlled MA and an ISP-controlled MA; then the test traffic of one= MA is treated by the other MA just like any other user traffic. Note that a single MA is instructed by a single Controller and is only in o= ne measurement system. The issue I see is that an LMAP system of Controller, MA and Collector is i= ncomplete. In the active measurement scenario, the user's MA needs a remote partner in= most cases. Sure, you could run the DNS measurement, or GET a web page. But to measure = anything interesting the user needs a partner: a Measurement Peer who runs a compatible test pro= tocol (unspecified by LMAP). - In user-deployed case 2, the Measurement Peer (MP) is likely to be opera= ted by a different organization (users have limited span of control) - The Measurement Peer's org. is likely to have access to some test result= s (through timestamps) and certainly an IP address. Users give-up some inf= o to get access to a Measurement Peer. So, case 2 seems to stretch the bounds of LMAP, because the LMAP-unspecifie= d measurement protocol between MA and MP spans org. boundaries, and conveys measurement info and u= ser info. Today's web-based testing services provide a partner IP addrs and a let you= see the results, but they keep copies of those things too. How can we negotiate the charter's privacy requirements in user-deployed ca= se 2? We might have to accept that the measurement protocol gives some info away. I'm interested to learn more from folks with experience in this area. Al From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: Tuesday, September 03, 2013 12:59 PM To: lmap@ietf.org Subject: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks We've now started creating an LMAP framework doc that merges 3 I-Ds (termin= ology and the 2 framework docs) - hoping it could be the basis for a WG doc= - as mentioned in Berlin. One section will be about proposed constraints /assumptions - extending htt= p://tools.ietf.org/html/draft-eardley-lmap-framework-02#section-3 I'm going to send a series of emails to try and capture where I think the d= iscussion got to in Berlin &/or propose text for the I-D &/or generate disc= ussion on open issues. Constraint: User-initiated Measurement Tasks out of scope of LMAP WG We expect LMAP & IPPM functionality to be used for user-initiated Measureme= nt Tasks, but the WG will not define how. There are at least two ways user-= initiation could happen, in outline * a user could somehow (perhaps via a webpage) request the ISP- (or regulat= or-) run measurement system to test his/her line. The ISP (or regulator) Co= ntroller would then send an Instruction to the MA in the usual LMAP way. Th= e Measurement Results could be returned back via the webpage. Note that a u= ser can't directly initiate a Measurement Task on an ISP- (or regulator-) c= ontrolled MA in their home * a user could deploy their own measurement system, with their own MA, Cont= roller and Collector (possibly with all three functions in the same box). T= he user may also want to report Measurement Results to a third party. One p= ossible situation is that the home contains a user-controlled MA and an ISP= -controlled MA; then the test traffic of one MA is treated by the other MA = just like any other user traffic. Note that a single MA is instructed by a = single Controller and is only in one measurement system. For further details see http://www.ietf.org/mail-archive/web/lmap/current/m= sg00714.html and related messages. Comments? Thanks phil --_000_2845723087023D4CB5114223779FA9C8A05B4DDFnjfpsrvexg8rese_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In what we now call case 2, the = user-deployed measurement system:

 

Phil wrote:

... There are at least two ways user-initiation could happen, in ou= tline

= <snip case 1&= gt;

* a user could dep= loy their own measurement system, with their own MA, Controller and Collect= or

(possibly with all= three functions in the same box). The user may also want to report

Measurement Results to a th= ird party. One possible situation is that the home contains

a user-controlled MA and an ISP-cont= rolled MA; then the test traffic of one MA is

treated by the other MA just like any other user t= raffic.

Note that a s= ingle MA is instructed by a single Controller and is only in one measuremen= t system.

 

The is= sue I see is that an LMAP system of Controller, MA and Collector is incompl= ete.

In the active measurement scenario, the user= 's MA needs a remote partner in most cases.

Sur= e, you could run the DNS measurement, or GET a web page. But to measure any= thing interesting

the user needs a partner: a Mea= surement Peer who runs a compatible test protocol

 =

-  In user-deployed case 2, the Measurement Peer (MP) is like= ly to be operated by a

   differe= nt organization (users have limited span of control)

<= p class=3DMsoNormal> 

-  The Measurement Peer's org. is= likely to have access to some test results

&nb= sp;  (through timestamps) and certainly an IP address. Users give-up s= ome info

   to get access to a Measurem= ent Peer.

 

So, ca= se 2 seems to stretch the bounds of LMAP, because the LMAP-unspecified meas= urement protocol

between MA and MP spans org. bou= ndaries, and conveys measurement info and user info.

<= p class=3DMsoNormal>Today's web-based testing services provide a partner IP addrs and a let= you see the results,

but they keep copies of tho= se things too.

 

H= ow can we negotiate the charter's privacy requirements in user-deployed cas= e 2?

We might have to accept that the measurement= protocol gives some info away.

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>I'm interested to= learn more from folks with experience in this area.

<= p class=3DMsoNormal> 

Al

&nbs= p;

 

<= p class=3DMsoNormal>From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org= ] On Behalf Of philip.eardley@bt.com
Sent: Tuesday, Septem= ber 03, 2013 12:59 PM
To: lmap@ietf.org
Subject: [lmap]= LMAP framework issue #1 User-initiated Measurement Tasks=

 

We&#= 8217;ve now started creating an LMAP framework doc that merges 3 I-Ds (term= inology and the 2 framework docs) – hoping it could be the basis for = a WG doc – as mentioned in Berlin.

=  

One section will be about propos= ed constraints /assumptions – extending http://tools.ietf.org/h= tml/draft-eardley-lmap-framework-02#section-3

 

I’m going to send = a series of emails to try and capture where I think the discussion got to i= n Berlin &/or propose text for the I-D &/or generate discussion on = open issues.

 

Constraint: User-initiated Measurement Tasks out of scope of = LMAP WG

We expect LMAP & IPPM functi= onality to be used for user-initiated Measurement Tasks, but the WG will no= t define how. There are at least two ways user-initiation could happen, in = outline

* a user could somehow (perhaps = via a webpage) request the ISP- (or regulator-) run measurement system to t= est his/her line. The ISP (or regulator) Controller would then send an Inst= ruction to the MA in the usual LMAP way. The Measurement Results could be r= eturned back via the webpage. Note that a user can’t directly initiat= e a Measurement Task on an ISP- (or regulator-) controlled MA in their home=

* a user could deploy their own measurem= ent system, with their own MA, Controller and Collector (possibly with all = three functions in the same box). The user may also want to report Measurem= ent Results to a third party. One possible situation is that the home conta= ins a user-controlled MA and an ISP-controlled MA; then the test traffic of= one MA is treated by the other MA just like any other user traffic. Note t= hat a single MA is instructed by a single Controller and is only in one mea= surement system.

For further details see= http://www.ietf.org/mail-archive/web/lmap/current/msg00714.html and r= elated messages.

 

Comments?

Thanks

phil

= --_000_2845723087023D4CB5114223779FA9C8A05B4DDFnjfpsrvexg8rese_-- From acmorton@att.com Tue Sep 10 08:41:27 2013 Return-Path: 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 B414921E8140 for ; Tue, 10 Sep 2013 08:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 mEPujXNwwqFr for ; Tue, 10 Sep 2013 08:41:23 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 689EB21E8123 for ; Tue, 10 Sep 2013 08:41:12 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 1061812059F; Tue, 10 Sep 2013 11:41:07 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (njfpsrvexg8.research.att.com [135.207.255.56]) by mail-green.research.att.com (Postfix) with ESMTP id 509CCE004A; Tue, 10 Sep 2013 11:40:51 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::a44a:8177:9a5d:ac00]) by njfpsrvexg8.research.att.com ([fe80::a44a:8177:9a5d:ac00%15]) with mapi; Tue, 10 Sep 2013 11:41:07 -0400 From: "MORTON, ALFRED C (AL)" To: "STARK, BARBARA H" , "Bugenhagen, Michael K" , "philip.eardley@bt.com" , "marcelo@it.uc3m.es" , "trevor.burbridge@bt.com" Date: Tue, 10 Sep 2013 11:41:06 -0400 Thread-Topic: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks Thread-Index: Ac6oxTl43dfkRXB1QZGOg/kNOKXELgAnOE4AAACr9QAAARJ7AAACVbCAAA7LiaAACvyiAAAHetggAQ4pxNA= Message-ID: <2845723087023D4CB5114223779FA9C8A05B4DDD@njfpsrvexg8.research.att.com> References: <5226E17E.5060009@it.uc3m.es> <5226ED32.9090604@it.uc3m.es> <2D09D61DDFA73D4C884805CC7865E6113035535C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130355452@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130355452@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 15:41:27 -0000 Sorry for joining this thread so late. Here's what I had at the end: Phil's points (now lettered) with Paul's clarification and Barbara's observ= ation: > A - make sure it's clear these are both possibilities, with various pros = and cons > B - clarify that in case 2 there'd be a GUI or mgt interface to request t= ests and see results=20 (just as this is mentioned for case 1) Paul: Say no more than it's some out-of-scope mechanism. It could be an ema= il,=20 SMS, intervention of local politician... LMAP doesn't know and doesn't=20 care, as long as the test sequence is initiated from the single=20 controller which is associated with the MA. > C - clarify that in case 2 - if a user reports Measurement Results to a t= hird party, these would be sent by the Collector and not direct from the MA Barb: I don't see a need to say this. ... This doesn't change the informati= on model,=20 doesn't change the list of potential Collector protocols, nor the data mod= els for those protocols. But .. say something about such an MA making sure the user has the c= hoice=20 and allowing the user to suppress sending of any info the user considers p= rivate.=20 and later Barb said: If it can test against a MP, is controlled by a single entity,=20 and can potentially report its info,=20 then (1) I don't see where having it in scope adds much complexity, and=20 (2) by having it in scope, that means things can be said about it.=20 For example, by having it in scope, it's possible to provide it with=20 guidance around how to interpret results and how to get and use service=20 attributes and how to play nice with others. And how to ensure customer pr= ivacy. This last idea has implications for item B, the request for tests and the r= esults. So we might recognize the overarching privacy consideration in the charter,= and say: B - clarify that in case 2 there'd be an *unspecified* interface to reque= st tests and see results=20 (just as this is mentioned for case 1), which will conform to LMAP gui= dance on privacy and user information control. C - clarify that in case 2 - if a user reports Measurement Results to ano= ther party, they have the option to suppress information in the report to conform to LMAP g= uidance on privacy and user information control. =20 (I have another discussion point with case 2, but I'll send that separately= .) Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > STARK, BARBARA H > Sent: Wednesday, September 04, 2013 6:36 PM > To: Bugenhagen, Michael K; philip.eardley@bt.com; marcelo@it.uc3m.es; > trevor.burbridge@bt.com > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement > Tasks >=20 > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information= . >=20 > > However I think Barbara is correct, a customer MA should be a "MA > > application"... BUT that is not LMAP it's a customer home test MA not > part of > > a larger system. > > > > So are we discussing a Large scale, or a Home testing component... or > both > > and how they fit together? > > > > Just doing a logic check.. >=20 > I was thinking of a MA that the customer downloads onto a customer-owned > device that tests the Internet connection. It may test against the same > MPs being used by entities that publish provider performance statistics. > It may even be provided by such an entity. I'm not thinking of a MA that > just tests the home network. I'm not thinking of how they fit together. >=20 > If it can test against a MP, is controlled by a single entity, and can > potentially report its info, then (1) I don't see where having it in scop= e > adds much complexity, and (2) by having it in scope, that means things ca= n > be said about it. For example, by having it in scope, it's possible to > provide it with guidance around how to interpret results and how to get > and use service attributes and how to play nice with others. And how to > ensure customer privacy. >=20 > When something is out of scope, there's no ability to say anything about > it. > If this customer-controlled MA is going to play in the same sandbox with > all the other little MAs, I'd prefer for it to abide by sandbox etiquette= . > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From acmorton@att.com Tue Sep 10 10:46:58 2013 Return-Path: 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 DAF3A21E8166 for ; Tue, 10 Sep 2013 10:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 BuSbesSYodR0 for ; Tue, 10 Sep 2013 10:46:52 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 7853621E8179 for ; Tue, 10 Sep 2013 10:46:52 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 4799F12049A; Tue, 10 Sep 2013 13:46:51 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (njfpsrvexg8.research.att.com [135.207.255.56]) by mail-green.research.att.com (Postfix) with ESMTP id 6CCD5E1F30; Tue, 10 Sep 2013 13:46:35 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::a44a:8177:9a5d:ac00]) by njfpsrvexg8.research.att.com ([fe80::a44a:8177:9a5d:ac00%15]) with mapi; Tue, 10 Sep 2013 13:46:51 -0400 From: "MORTON, ALFRED C (AL)" To: "philip.eardley@bt.com" , "marcelo@it.uc3m.es" , "lmap@ietf.org" Date: Tue, 10 Sep 2013 13:46:50 -0400 Thread-Topic: [lmap] LMAP Framework issue #2 Admission control and measurement suppression Thread-Index: Ac6pTBtkORmQkyh6SmOZSiJpnh+MaQABaikwAT5RPQA= Message-ID: <2845723087023D4CB5114223779FA9C8A05B4E4E@njfpsrvexg8.research.att.com> References: <5226F4CB.1050403@it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:46:59 -0000 Again late to the party, comments below: > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: Wednesday, September 04, 2013 5:50 AM > To: marcelo@it.uc3m.es; lmap@ietf.org > Subject: Re: [lmap] LMAP Framework issue #2 Admission control and > measurement suppression >=20 > > > In addition the Controller may want to send a "suppress" message to > > > some MAs so that they temporarily stop performing Active Measurement > > > Tasks - perhaps there is some unexpected network issue and the ISP > > > wants to eliminate inessential traffic. Since some Measurement Tasks > > > involve the MP sending traffic to the MA, so this suggests the MA may > > > sometimes need to send a "suppress" message to the MP. > > > > > > > I agree we need this. > > > > We had a discussion about this a while ago and one specific issue that > > i found very useful is to distinguish between measurements that are > > running and measurements that are schedulled to run. > > > > Suppose you have schedulled to run 10 TCP throughput tests that last 5 > > seconds each and they are to be executed every 5 minutes. > > > > Suppose that at time T1 the MA is running the first of the TCP throuput > > tests. > > > > Suppose that at time T1 we send the suppress message: what are > > expecting to suppress? > > a- abort the ongoing test and suppress the next 9 tests, or, > > b- finnish the ongoing test and suppress the next 9 tests > > > > I think b is easy, b not so much. >=20 > [phil] this is a very good point. > Assuming you mean "b is easy, a not so much" - I agree > Would it be a reasonable target is for suppression to solve b, but in > general not a (perhaps it would be possible for some tests, but not a > general capability)? >=20 Like everyone else, I think we need suppression, with or without report. Most MA - MP test protocols we might use allow some way for the MA to abort= the=20 measurement in-progress. The only case I can think-up where abort is diffic= ult is where the MP is sending an un-acknowledged packet stream, and there is n= o test control protocol available for the MA to say "STOP". In TWAMP, the Stop control or the MA suspending transmission will eventuall= y starve the MP in a "responder" role (operating normally in "send-on-receive= "), and starving the MP would work in other protocols with a responder, too. With a TCP download from MP, the MA could send Zero-Window or ditch the con= nection. So, I think we might solve *almost* all the abort cases by telling the MA a= nd=20 relying on the measurement protocol features or mandatory Transport Protoco= l feedback. Abort cannot be mandatory, but could be Recommended. Al From marcelo@it.uc3m.es Tue Sep 10 23:32:24 2013 Return-Path: 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 6067B11E816E for ; Tue, 10 Sep 2013 23:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ehYe8yPSe2dU for ; Tue, 10 Sep 2013 23:32:18 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3F07B11E812C for ; Tue, 10 Sep 2013 23:32:18 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B25AC86B248; Wed, 11 Sep 2013 08:32:16 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost25.it.uc3m.es (dummyhost27.it.uc3m.es [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id A5AC286B224; Wed, 11 Sep 2013 08:32:16 +0200 (CEST) Message-ID: <52300E71.1050100@it.uc3m.es> Date: Wed, 11 Sep 2013 08:32:17 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" References: <5226F4CB.1050403@it.uc3m.es> <2845723087023D4CB5114223779FA9C8A05B4E4E@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8A05B4E4E@njfpsrvexg8.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Wed, 11 Sep 2013 08:32:16 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20140.004 X-TM-AS-Result: No--23.227-7.0-31-1 X-imss-scan-details: No--23.227-7.0-31-1 Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 06:32:24 -0000 El 10/09/13 19:46, MORTON, ALFRED C (AL) escribió: > Again late to the party, comments below: > >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >> philip.eardley@bt.com >> Sent: Wednesday, September 04, 2013 5:50 AM >> To: marcelo@it.uc3m.es; lmap@ietf.org >> Subject: Re: [lmap] LMAP Framework issue #2 Admission control and >> measurement suppression >> >>>> In addition the Controller may want to send a "suppress" message to >>>> some MAs so that they temporarily stop performing Active Measurement >>>> Tasks - perhaps there is some unexpected network issue and the ISP >>>> wants to eliminate inessential traffic. Since some Measurement Tasks >>>> involve the MP sending traffic to the MA, so this suggests the MA may >>>> sometimes need to send a "suppress" message to the MP. >>>> >>> I agree we need this. >>> >>> We had a discussion about this a while ago and one specific issue that >>> i found very useful is to distinguish between measurements that are >>> running and measurements that are schedulled to run. >>> >>> Suppose you have schedulled to run 10 TCP throughput tests that last 5 >>> seconds each and they are to be executed every 5 minutes. >>> >>> Suppose that at time T1 the MA is running the first of the TCP throuput >>> tests. >>> >>> Suppose that at time T1 we send the suppress message: what are >>> expecting to suppress? >>> a- abort the ongoing test and suppress the next 9 tests, or, >>> b- finnish the ongoing test and suppress the next 9 tests >>> >>> I think b is easy, b not so much. >> [phil] this is a very good point. >> Assuming you mean "b is easy, a not so much" - I agree >> Would it be a reasonable target is for suppression to solve b, but in >> general not a (perhaps it would be possible for some tests, but not a >> general capability)? >> > Like everyone else, I think we need suppression, with or without report. > > Most MA - MP test protocols we might use allow some way for the MA to abort the > measurement in-progress. The only case I can think-up where abort is difficult > is where the MP is sending an un-acknowledged packet stream, and there is no > test control protocol available for the MA to say "STOP". > > In TWAMP, the Stop control or the MA suspending transmission will eventually > starve the MP in a "responder" role (operating normally in "send-on-receive"), > and starving the MP would work in other protocols with a responder, too. > > With a TCP download from MP, the MA could send Zero-Window or ditch the connection. > > So, I think we might solve *almost* all the abort cases by telling the MA and > relying on the measurement protocol features or mandatory Transport Protocol > feedback. Abort cannot be mandatory, but could be Recommended. right, but this seems specific to the test the MA is performing, so it is unclear to me if we can build this into the lmap protocol as a generic feature, no? > Al > > From acmorton@att.com Wed Sep 11 04:29:06 2013 Return-Path: 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 8367B21E80D8 for ; Wed, 11 Sep 2013 04:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.932 X-Spam-Level: X-Spam-Status: No, score=-106.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 bQZm9m523+LC for ; Wed, 11 Sep 2013 04:29:00 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4E04421E80D4 for ; Wed, 11 Sep 2013 04:29:00 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id E1300120588; Wed, 11 Sep 2013 07:28:58 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (njfpsrvexg8.research.att.com [135.207.255.56]) by mail-green.research.att.com (Postfix) with ESMTP id C954CE0E0B; Wed, 11 Sep 2013 07:28:41 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::a44a:8177:9a5d:ac00]) by njfpsrvexg8.research.att.com ([fe80::a44a:8177:9a5d:ac00%15]) with mapi; Wed, 11 Sep 2013 07:28:59 -0400 From: "MORTON, ALFRED C (AL)" To: marcelo bagnulo braun Date: Wed, 11 Sep 2013 07:28:58 -0400 Thread-Topic: [lmap] LMAP Framework issue #2 Admission control and measurement suppression Thread-Index: Ac6uuLKAJbZjLQhIRRCPpCIUWJslLgAJxtUg Message-ID: <2845723087023D4CB5114223779FA9C8AAC20F00@njfpsrvexg8.research.att.com> References: <5226F4CB.1050403@it.uc3m.es> <2845723087023D4CB5114223779FA9C8A05B4E4E@njfpsrvexg8.research.att.com> <52300E71.1050100@it.uc3m.es> In-Reply-To: <52300E71.1050100@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 11:29:06 -0000 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] ... > Al wrote: > > So, I think we might solve *almost* all the abort cases by telling the = MA and > > relying on the measurement protocol features or mandatory Transport Pro= tocol > > feedback. Abort cannot be mandatory, but could be Recommended. >=20 > right, but this seems specific to the test the MA is performing, so it > is unclear to me if we can build this into the lmap protocol as a > generic feature, no? >=20 >=20 Hi Marcelo, I must be missing some detail -=20 if we can build an effective suppression message into LMAP Control protocol to cover cases "a" and "b", knowing that "a" will not always be possible: >>> a- abort the ongoing test and suppress the next 9 tests, or, >>> b- finish the ongoing test and suppress the next 9 tests and the MA can receive an unexpected LMAP Control message=20 and take immediate action on the measurement function=20 (whether passive or active, OWAMP, TWAMP, IPSLA, TCP, ping, other)=20 then it seems there are enough pieces to make suppression/abort work. what am I missing?=20 Al From marcelo@it.uc3m.es Thu Sep 12 00:01:14 2013 Return-Path: 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 D96CC11E8254 for ; Thu, 12 Sep 2013 00:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 IPosapkf5X-n for ; Thu, 12 Sep 2013 00:01:04 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9E17611E8175 for ; Thu, 12 Sep 2013 00:00:49 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CFAFE86B919; Thu, 12 Sep 2013 09:00:43 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost0.it.uc3m.es (dummyhost0.it.uc3m.es [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id C293A766EC8; Thu, 12 Sep 2013 09:00:43 +0200 (CEST) Message-ID: <5231669C.8020703@it.uc3m.es> Date: Thu, 12 Sep 2013 09:00:44 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" References: <5226F4CB.1050403@it.uc3m.es> <2845723087023D4CB5114223779FA9C8A05B4E4E@njfpsrvexg8.research.att.com> <52300E71.1050100@it.uc3m.es> <2845723087023D4CB5114223779FA9C8AAC20F00@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8AAC20F00@njfpsrvexg8.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Thu, 12 Sep 2013 09:00:43 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20144.005 X-TM-AS-Result: No--18.883-7.0-31-1 X-imss-scan-details: No--18.883-7.0-31-1 Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP Framework issue #2 Admission control and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 07:01:15 -0000 El 11/09/13 13:28, MORTON, ALFRED C (AL) escribió: >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > ... >> Al wrote: >>> So, I think we might solve *almost* all the abort cases by telling the MA and >>> relying on the measurement protocol features or mandatory Transport Protocol >>> feedback. Abort cannot be mandatory, but could be Recommended. >> right, but this seems specific to the test the MA is performing, so it >> is unclear to me if we can build this into the lmap protocol as a >> generic feature, no? >> >> > Hi Marcelo, > > I must be missing some detail - > > if we can build an effective suppression message into LMAP Control protocol > to cover cases "a" and "b", knowing that "a" will not always be possible: >>>> a- abort the ongoing test and suppress the next 9 tests, or, >>>> b- finish the ongoing test and suppress the next 9 tests > and the MA can receive an unexpected LMAP Control message > and take immediate action on the measurement function > (whether passive or active, OWAMP, TWAMP, IPSLA, TCP, ping, other) > then it seems there are enough pieces to make suppression/abort work. > > what am I missing? right, the thing is that the actual effect of the suppression message would be dependent on the test being executed, as you say. I am not sure this is a good idea. Maybe it is the best we can do. Not sure at this point. Regards, marcelo > > Al > > From philip.eardley@bt.com Thu Sep 12 07:46:36 2013 Return-Path: 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 F372111E81B1 for ; Thu, 12 Sep 2013 07:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.307 X-Spam-Level: X-Spam-Status: No, score=-103.307 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 8VepOXJfhXYK for ; Thu, 12 Sep 2013 07:46:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id E53DC11E8117 for ; Thu, 12 Sep 2013 07:46:25 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 12 Sep 2013 15:46:23 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 12 Sep 2013 15:46:23 +0100 From: To: Date: Thu, 12 Sep 2013 15:46:22 +0100 Thread-Topic: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller Thread-Index: AQHOqjPJrjThnUMrtEK9647rdf2qjZm3IzZwgAsV8sA= Message-ID: References: <7A90536F-BECD-4C7D-8CAF-EC8EF6422A41@tik.ee.ethz.ch> <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113035577E@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 14:46:36 -0000 Barbara I think you convinced me. I'll work on a revised summary text Thanks phil > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: 05 September 2013 14:58 > To: Eardley,PL,Philip,TUB8 R > Cc: lmap@ietf.org > Subject: RE: [lmap] LMAP Framework issue #3 No negotiation between MA > and Controller >=20 > Not sure which email in this thread to start from, so I just cleaned > out all other text... >=20 > Advertisement: > This is a really simple thing to do, and any good control protocol with > a well-designed data model should be perfectly capable of this. It is > not part of bootstrap. > For example, if TR-069 were being used as the control protocol (and, > yes, I'm talking about Control and not bootstrap), there would be an > xml parameter that lists capabilities, as well as xml parameters that > match up to the enabling/disabling/execution of these capabilities, and > setting of specific parameters associated with these capabilities. Via > this exemplary TR-069 interface, the Controller can request the MA tell > the Controller (1) the entire data model structure (every single xml > parameter) and (2) the current values of these xml parameters (e.g., > the current value of a capability list xml parameter). It's not > necessary to get this info every time. Important changes can be > "evented", so the Controller is informed either that changes have > occurred, and even what changes have occurred. >=20 > IMO, lmap should not recommend a protocol that isn't capable of such > incredibly basic functionality. >=20 > Negotiation: > I don't know that I would call it a negotiation as much as the MA > having proper ways to tell the Controller "No". Again, using TR-069 as > an example, if the Controller tells the MA to set xml parameters that > the MA doesn't have in its TR-069 data model, then the MA can say "No, > I don't have those parameters." If the Controller tells the MA to set > xml parameters that have been locked so they cannot be written to, then > the MA tells the Controller "No, those are locked". If there is some > temporary reason the MA can't comply, then the MA needs to tell the > Controller "No, not right now". >=20 > Similarly, if a test were scheduled to be run by the Controller, and > the MA doesn't run it for some reason, there should be an xml parameter > that gives the reason why the test wasn't run (a status or result > parameter). The allowed values defined for this parameter need to > provide the necessary level of information to the Controller. When the > Controller reads the value of that parameter, it gets the info it > needs. >=20 > Since I know that TR-069 can easily do advertisement and negotiation > with a well-designed data model (and, yes, in TR-069 this level of > communication is done through data model parameters and their values > and not through specific/different RPCs or RPC error messages), I'm > not understanding why there's debate about whether or not these should > be criteria in Control protocol selection and requirements when doing > that protocol's data model design. IMO, of course they're required. > Barbara >=20 From philip.eardley@bt.com Thu Sep 12 08:45:41 2013 Return-Path: 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 0EA3711E8242 for ; Thu, 12 Sep 2013 08:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.568 X-Spam-Level: X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 lNfa8gg1140y for ; Thu, 12 Sep 2013 08:45:35 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEFA11E8234 for ; Thu, 12 Sep 2013 08:45:08 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 12 Sep 2013 16:44:35 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 12 Sep 2013 16:44:35 +0100 From: To: Date: Thu, 12 Sep 2013 16:44:34 +0100 Thread-Topic: LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYA== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF94B0A52EMV67UKRDdoma_" MIME-Version: 1.0 Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:45:41 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF94B0A52EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF94B0A52EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the nice = discussion, I’ve tried to re-write to reflect where I think we’= ve got to. I also changed the title to:

Interactions between MA and= Controller

As part of a bootstrap pr= ocess the MA gets sufficient information to contact a Controller. Defining = a bootstrap mechanism is out of scope of the LMAP WG.

=

 

The basic int= eraction between a Controller and MA is that the Controller sends an Instru= ction to the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the mea= surement system understands what Measurement Methods the MA can do and ther= efore the Controller can simply instruct the MA; there is no need for a neg= otiation protocol (which would add complexity to the MA, Controller and Con= trol Protocol). However, it is possible that the MA is in fact not capable = of performing the requested Measurement Method, and so the Control Protocol= must allow the MA to reply with a suitable error code. <= /p>

 

The MA can= send to the Controller the list of Measurement Methods that it is capable = of. This could be useful:

[1] as part= of the MA registering with the Controller. Note that in some scenarios it = is not needed, as the Controller will know the information by other means, = for example as part of the bootstrapping process (using Tr-069 say) or beca= use the MA is statically configured.

= [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method.

** Comment: sug= gest we keep it simple and just send the complete list, rather than a delta= . The message should be short, since Methods are referred to via a registry= .

[3] when requested by the Controlle= r, which could be useful if ‘something goes wrong’ and the Cont= roller forgets what the MA can do.

<= o:p> 

Note that the advert contains t= he list of Measurement Methods that the MA can perform. It is not intended = to indicate dynamic capabilities like the MA’s currently unused CPU, = memory or battery life.

** Comment: = I’m not sure whether we reached consensus on this point. <= /span>

 

It = is possible that later, when a MA is implementing the Instruction, it does = not perform a particular Measurement Task for some reason, such as: the Mea= surement Peer is busy, or there is cross-traffic, … The MA doesn̵= 7;t inform the Controller, instead it is reported to the Collector as part = of the Measurement Report. The Collector may in turn tell the measurement s= ystem or even the Controller, but this is out of scope of LMAP.<= /span>

** Comment: are there any conditions when itR= 17;s critical for the Controller to be informed?

 

&= nbsp;

From: lm= ap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com
Sent: 05 September 2013 11:13
To: lma= p@ietf.org
Subject: [lmap] LMAP Framework issue #3 No negotiation= between MA and Controller

 

Another issue:

There is no negotiation between the MA and Controller= - the Controller simply sends the Instruction to the MA, with the details = of the Measurement Tasks to perform.

In general we expect that the measurement system understands the capabilit= ies of its MAs (probably there are only one or a few classes of MA), so neg= otiation about the MA’s capabilities would have little benefit. It wo= uld also add complexity to the MA, Controller and Control Protocol.

 

Thoughts? =

Thanks

phil=

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF94B0A52EMV67UKRDdoma_-- From sharam.hakimi@exfo.com Thu Sep 12 09:18:57 2013 Return-Path: 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 E720311E819A for ; Thu, 12 Sep 2013 09:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rl0gBL-7BiGZ for ; Thu, 12 Sep 2013 09:18:31 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 23D2621E8129 for ; Thu, 12 Sep 2013 09:17:13 -0700 (PDT) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Sep 2013 12:16:42 -0400 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Sep 2013 12:16:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CEAFD3.73C5BB68" Date: Thu, 12 Sep 2013 12:16:31 -0400 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02804B12@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABiEdQ References: From: "Sharam Hakimi" To: , X-OriginalArrivalTime: 12 Sep 2013 16:16:41.0643 (UTC) FILETIME=[776597B0:01CEAFD3] Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:18:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CEAFD3.73C5BB68 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Phil, Great caption, couple of suggestions: =20 Change: As part of a bootstrap process the MA gets sufficient information to contact a Controller. =20 To:=20 Either as part of a bootstrap process or through pre-configuration the MA will have sufficient information to contact a Controller. =20 =20 As for the last question: are there any conditions when it's critical for the Controller to be informed? =20 Unless there is a defined critical test time, not that I think one is necessary, that a test needs to have a set of results, I do not think that the controller would need to inform the controller that a test could not be performed. I think that would add a lot of unnecessary complexity. =20 Thanks, Sharam =20 From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller =20 Thanks for the nice discussion, I've tried to re-write to reflect where I think we've got to. I also changed the title to: =20 Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contact a Controller. Defining a bootstrap mechanism is out of scope of the LMAP WG. =20 The basic interaction between a Controller and MA is that the Controller sends an Instruction to the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect that the measurement system understands what Measurement Methods the MA can do and therefore the Controller can simply instruct the MA; there is no need for a negotiation protocol (which would add complexity to the MA, Controller and Control Protocol). However, it is possible that the MA is in fact not capable of performing the requested Measurement Method, and so the Control Protocol must allow the MA to reply with a suitable error code.=20 =20 The MA can send to the Controller the list of Measurement Methods that it is capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some scenarios it is not needed, as the Controller will know the information by other means, for example as part of the bootstrapping process (using Tr-069 say) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new Measurement Method.=20 ** Comment: suggest we keep it simple and just send the complete list, rather than a delta. The message should be short, since Methods are referred to via a registry. [3] when requested by the Controller, which could be useful if 'something goes wrong' and the Controller forgets what the MA can do.=20 =20 Note that the advert contains the list of Measurement Methods that the MA can perform. It is not intended to indicate dynamic capabilities like the MA's currently unused CPU, memory or battery life.=20 ** Comment: I'm not sure whether we reached consensus on this point.=20 =20 It is possible that later, when a MA is implementing the Instruction, it does not perform a particular Measurement Task for some reason, such as: the Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inform the Controller, instead it is reported to the Collector as part of the Measurement Report. The Collector may in turn tell the measurement system or even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller to be informed? =20 =20 From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller =20 Another issue: There is no negotiation between the MA and Controller - the Controller simply sends the Instruction to the MA, with the details of the Measurement Tasks to perform.=20 In general we expect that the measurement system understands the capabilities of its MAs (probably there are only one or a few classes of MA), so negotiation about the MA's capabilities would have little benefit. It would also add complexity to the MA, Controller and Control Protocol.=20 =20 It is possible that the MA can't perform the requested Measurement Task. So the Control Protocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to send a list of all the Measurement Methods that it is capable of, in case 'something goes wrong' and the Controller forgets what the MA can do. Comment: this idea hasn't had much discussion yet, but appears in the Information Model i-d =20 Thoughts?=20 Thanks phil ------_=_NextPart_001_01CEAFD3.73C5BB68 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Phil,

Great caption, couple = of suggestions:

 

Change:

As part of a bootstrap process the MA gets sufficient information to = contact a Controller.

 

To:

Either as part of a bootstrap process or through = pre-configuration the MA will have sufficient information to contact a = Controller.

 

 

As for the last question: are there any conditions when it’s critical = for the Controller to be informed?

 

Unless there is a = defined critical test time, not that I think one is necessary, that a test needs to have = a set of results, I do not think that the controller would need to inform the controller that a test could not be performed. I think that would add a = lot of unnecessary complexity.

 

Thanks,

Sharam

 

From:= = lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: Thursday, September 12, 2013 11:45 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions = between MA and Controller

 

Thanks for the nice discussion, I’ve tried to re-write to reflect where I = think we’ve got to. I also changed the title to:

 

Interactions between MA and Controller

As part of a bootstrap process the MA gets sufficient information to = contact a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG.

 

The basic interaction between a Controller and MA is that the Controller = sends an Instruction to the MA, detailing what Measurement Tasks to do, when to = do them, and how to report the Measurement Results. In general we expect that the measurement system understands what Measurement Methods the MA can do = and therefore the Controller can simply instruct the MA; there is no need = for a negotiation protocol (which would add complexity to the MA, Controller = and Control Protocol). However, it is possible that the MA is in fact not = capable of performing the requested Measurement Method, and so the Control = Protocol must allow the MA to reply with a suitable error code. =

 

The MA can send to the Controller the list of Measurement Methods that it is capable of. This could be useful:

[1] as part of the MA registering with the Controller. Note that in some = scenarios it is not needed, as the Controller will know the information by other = means, for example as part of the bootstrapping process (using Tr-069 say) or = because the MA is statically configured.

[2] so the MA can re-register, for example if it becomes capable of a new Measurement Method.

** Comment: suggest we keep it simple and just send the complete list, = rather than a delta. The message should be short, since Methods are referred to via = a registry.

[3] when requested by the Controller, which could be useful if = ‘something goes wrong’ and the Controller forgets what the MA can do. =

 

Note that the advert contains the list of Measurement Methods that the MA can perform. It is not intended to indicate dynamic capabilities like the MA’s currently unused CPU, memory or battery life. =

** Comment: I’m not sure whether we reached consensus on this point. =

 

It is possible that later, when a MA is implementing the Instruction, it = does not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, … The MA doesn’t = inform the Controller, instead it is reported to the Collector as part of the Measurement Report. The Collector may in turn tell the measurement = system or even the Controller, but this is out of scope of = LMAP.

** Comment: are there any conditions when it’s critical for the = Controller to be informed?

 

 

From:= lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: 05 September 2013 11:13
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 No negotiation between MA = and Controller

 

Another issue:

There is no negotiation between the MA and Controller - the Controller simply = sends the Instruction to the MA, with the details of the Measurement Tasks to perform.

In general we expect that the measurement system understands the = capabilities of its MAs (probably there are only one or a few classes of MA), so = negotiation about the MA’s capabilities would have little benefit. It would = also add complexity to the MA, Controller and Control Protocol. =

 

It is possible that the MA can’t perform the requested Measurement = Task. So the Control Protocol needs to allow the MA to reply with an error code. = It has also been suggested that the Controller should be able to ask the MA to = send a list of all the Measurement Methods that it is capable of, in case ‘something goes wrong’ and the Controller forgets what the = MA can do. Comment: this idea hasn’t had much discussion yet, but appears = in the Information Model i-d

 

Thoughts?

Thanks

phil

------_=_NextPart_001_01CEAFD3.73C5BB68-- From philip.eardley@bt.com Thu Sep 12 09:41:08 2013 Return-Path: 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 766AD21E80FC for ; Thu, 12 Sep 2013 09:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 8aIdJfKCX7kW for ; Thu, 12 Sep 2013 09:41:03 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id EB35C21E80D1 for ; Thu, 12 Sep 2013 09:40:46 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 12 Sep 2013 17:40:44 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 12 Sep 2013 17:40:44 +0100 From: To: Date: Thu, 12 Sep 2013 17:40:42 +0100 Thread-Topic: LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks Thread-Index: Ac6v01KU2a3Wf+b8SYetGTOZ7cCdjQ== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF94B0A80EMV67UKRDdoma_" MIME-Version: 1.0 Subject: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:41:08 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF94B0A80EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the great discussion about this point as well. again I adjusted = the title. I think we converged on this issue - well let's see if I'm wrong= ! Starting and stopping Measurement Tasks Many Active Measurement Tasks begin with a pre-check before the test traffi= c is sent. Action could include: * the MA checking that there is no cross-traffic (ie that the user isn't a= lready sending traffic); * the MA checking with the Measurement Peer that it can handle a new Measu= rement Task (in case the MP is already handling many Measurement Tasks with= other MAs); * the first part of the Measurement Task consisting of traffic that probes= the path to make sure it isn't overloaded. It is possible that similar checks continue during the Measurement Task, es= pecially one that is long-running &/or creates a lot of traffic, and it is = abandoned whilst in-progress. Action could include: * For 'upload' tests, the MA not sending traffic * For 'download' tests, the MA closing the TCP connection or sendin= g a TWAMP Stop control message. If there is some unexpected network issue, the measurement system may want = to eliminate inessential traffic. Therefore the Controller has the ability = to send a "suppress" message to MAs. As a result, temporarily the MA does n= ot start new Active Measurement Tasks, and it may also stop in-progress Mea= surement Tasks, especially ones that are long-running &/or creates a lot of= traffic. The LMAP WG does not define a generic start and stop process, since the cor= rect approach depend on the particular Measurement Task; the details are de= fined as part of each Measurement Method, and hence potentially by the IPPM= WG. This also means that the LMAP framework doesn't define a coordination = process between MAs; whilst a measurement system may define coordinated Mea= surement Schedules across its various MAs, there is no direct coordination = between MAs. The MA does not inform the Controller about Measurement Tasks starting or s= topping. The Measurement Report includes the start and end of suppression, = and it labels (or perhaps doesn't include) Measurement Results impacted by = for instance cross-traffic. From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: 03 September 2013 18:23 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #2 Admission control and measurement s= uppression Another issue.... Admission control functionality pre-checks that it is a suitable moment to = carry out a Measurement Task. It is the job of the Measurement Method to de= fine such a pre-check - hence this is in the scope of IPPM rather than LMAP= . Action could include: * the MA checking that there is no cross-traffic (ie that the user isn't a= lready sending traffic) before the Measurement Task starts sending traffic; * the first part of the Measurement Task consisting of the MA asking the M= easurement Peer whether it can send test traffic; * the first part of the Measurement Task consisting of traffic that probes= the path to make sure it isn't overloaded; * the Measurement Task detecting the presence of cross-traffic after the M= A (&/or MP) has started sending traffic. Note that the LMAP WG does not define a generic admission control process, = since the correct approach depends on the particular Measurement Task. This= also means that the framework doesn't define a coordination process betwee= n MAs; whilst a measurement system may define coordinated Measurement Sched= ules across its various MAs, there is no direct coordination between MAs. In addition the Controller may want to send a "suppress" message to some MA= s so that they temporarily stop performing Active Measurement Tasks - perha= ps there is some unexpected network issue and the ISP wants to eliminate in= essential traffic. Since some Measurement Tasks involve the MP sending traf= fic to the MA, so this suggests the MA may sometimes need to send a "suppre= ss" message to the MP. Discussion needed... 1. the Broadband Forum liaison mentioned a generic admission process, but m= y impression is that people no longer think this is needed. Just wanted to = make sure I got that right. 2. I've heard a couple of comments that suppression is needed, but we haven= 't had much discussion - do people agree? 3. the Information Model should discuss how suppression gets recorded in th= e results (perhaps the on-going results get scrapped - perhaps the results = are marked with a warning - perhaps it depends on the metric?) 4. suppress is a bit messy if the MP is sending traffic to the MA (eg downl= oad speed test). One MP may be sending to several MAs. perhaps the suppress= msg should go directly to the MP? Of course if the MP doesn't have lmap fu= nctionality then there's nothing that can be done in any case. Comments? Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF94B0A80EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the great= discussion about this point as well. again I adjusted the title. I think w= e converged on this issue – well let’s see if I’m wrong!<= o:p>

 

Starting and stopping Measurement Tasks

Many Active Measurement Tasks begin with a pre-check before the= test traffic is sent. Action could include:

*  the MA checking that there is no cross-traffic (ie that th= e user isn’t already sending traffic);

*  the MA checking with the Measurement Peer that it can hand= le a new Measurement Task (in case the MP is already handling many Measurem= ent Tasks with other MAs);

*  th= e first part of the Measurement Task consisting of traffic that probes the = path to make sure it isn’t overloaded.

 

It is possible that s= imilar checks continue during the Measurement Task, especially one that is = long-running &/or creates a lot of traffic, and it is abandoned whilst = in-progress. Action could include:

·&nbs= p;        For= ‘upload’ tests, the MA not sending traffic

·         For ‘download’ tests, the MA closing the TCP = connection or sending a TWAMP Stop control message.

 

If there is some unexpected netw= ork issue, the measurement system may want to eliminate inessential traffic= . Therefore the Controller has the ability to send a “suppress”= message to MAs. As a result, temporarily the MA does not start new Active = Measurement Tasks, and it may also stop in-progress Measurement Tasks, e= specially ones that are long-running &/or creates a lot of traffic.

 

The LM= AP WG does not define a generic start and stop process, since the correct a= pproach depend on the particular Measurement Task; the details are defined = as part of each Measurement Method, and hence potentially by the IPPM WG. T= his also means that the LMAP framework doesn’t define a coordination = process between MAs; whilst a measurement system may define coordinated Mea= surement Schedules across its various MAs, there is no direct coordination = between MAs.

 =

The MA does not inform the Controller about Measuremen= t Tasks starting or stopping. The Measurement Report includes the start and= end of suppression, and it labels (or perhaps doesn’t include) Measu= rement Results impacted by for instance cross-traffic.

 

From: lmap-bounces@ietf.org [mailto:lmap-bounce= s@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 03 Se= ptember 2013 18:23
To: lmap@ietf.org
Subject: [lmap] LM= AP Framework issue #2 Admission control and measurement suppression

 

Another= issue….

 

Admission c= ontrol functionality pre-checks that it is a suitable moment to carry out a= Measurement Task. It is the job of the Measurement Method to define such a= pre-check – hence this is in the scope of IPPM rather than LMAP. Act= ion could include:

*  the MA checking that there = is no cross-traffic (ie that the user isn’t already sending traffic) = before the Measurement Task starts sending traffic;

<= p class=3DMsoNormal>*=   the first part of the Measurement Task consisting of the MA asking t= he Measurement Peer whether it can send test traffic;

=

= *  the first part of the Measurement Task consisting of traffic that p= robes the path to make sure it isn’t overloaded;

*  the Measurement Task detecting the presence of cross-traffic after= the MA (&/or MP) has started sending traffic.

 

Note that the LMAP WG does not define a generic ad= mission control process, since the correct approach depends on the particul= ar Measurement Task. This also means that the framework doesn’t defin= e a coordination process between MAs; whilst a measurement system may defin= e coordinated Measurement Schedules across its various MAs, there is no dir= ect coordination between MAs.

 

In addition the Controller may want to send a “suppress” m= essage to some MAs so that they temporarily stop performing Active Measurem= ent Tasks – perhaps there is some unexpected network issue and the IS= P wants to eliminate inessential traffic. Since some Measurement Tasks invo= lve the MP sending traffic to the MA, so this suggests the MA may sometimes= need to send a “suppress” message to the MP.=

 

 

Discussion need= ed…

1. the Broadband Forum liaison mentioned a g= eneric admission process, but my impression is that people no longer think = this is needed. Just wanted to make sure I got that right.

2. I’ve heard a couple of comments that suppression is needed, = but we haven’t had much discussion – do people agree?

3. the Information Model should discuss how suppression gets re= corded in the results (perhaps the on-going results get scrapped – pe= rhaps the results are marked with a warning – perhaps it depends on t= he metric?)

4. suppress is a bit messy if the MP is se= nding traffic to the MA (eg download speed test). One MP may be sending to = several MAs. perhaps the suppress msg should go directly to the MP? Of cour= se if the MP doesn’t have lmap functionality then there’s nothi= ng that can be done in any case.

 

Comments?

Thanks

phil

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF94B0A80EMV67UKRDdoma_-- From j.schoenwaelder@jacobs-university.de Thu Sep 12 10:01:24 2013 Return-Path: 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 3F85121E819B for ; Thu, 12 Sep 2013 10:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ZhGaATjTVvOx for ; Thu, 12 Sep 2013 10:01:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B732E21E815B for ; Thu, 12 Sep 2013 10:01:10 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABAB820C11; Thu, 12 Sep 2013 19:01:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YPJfIRsp78fz; Thu, 12 Sep 2013 19:01:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BF8D20C0C; Thu, 12 Sep 2013 19:01:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3AB96284F811; Thu, 12 Sep 2013 19:01:00 +0200 (CEST) Date: Thu, 12 Sep 2013 19:01:00 +0200 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20130912170100.GB58020@elstar.local> Mail-Followup-To: Sharam Hakimi , philip.eardley@bt.com, lmap@ietf.org References: <084CDC75FEC1E640B60338273BEACDFA02804B12@spboexc01.exfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02804B12@spboexc01.exfo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 17:01:24 -0000 On Thu, Sep 12, 2013 at 12:16:31PM -0400, Sharam Hakimi wrote: > Phil, > > Great caption, couple of suggestions: > > > > Change: > > As part of a bootstrap process the MA gets sufficient information to > contact a Controller. > > > > To: > > Either as part of a bootstrap process or through pre-configuration the > MA will have sufficient information to contact a Controller. > > For me, pre-configuration is one way of bootstrapping. Hence I believe the original text was sufficient and the addition is not needed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bs7652@att.com Thu Sep 12 11:35:17 2013 Return-Path: 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 38CDE21E809D for ; Thu, 12 Sep 2013 11:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 U0vi0vUkPnQ8 for ; Thu, 12 Sep 2013 11:35:10 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 75CF821E815D for ; Thu, 12 Sep 2013 11:35:01 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 55902325.58c3a940.521188.00-580.1434858.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 12 Sep 2013 18:35:01 +0000 (UTC) X-MXL-Hash: 5232095520c2a928-050455604ff1f3ad9c8bd8d0d1e00c9e6a63e47b Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id a4902325.0.521027.00-211.1434379.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 12 Sep 2013 18:34:51 +0000 (UTC) X-MXL-Hash: 5232094b137b3321-8c4d60608ab978ac73a34025589c6effad6d04d4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8CIYoti006753; Thu, 12 Sep 2013 14:34:50 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8CIYdnt006618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 14:34:45 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 12 Sep 2013 18:34:33 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0158.001; Thu, 12 Sep 2013 14:34:30 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiw Date: Thu, 12 Sep 2013 18:34:24 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.102.104] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6113036E14CGAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=ONCQK1mB c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ZimPP_EEygoA:10 a=l4EBnxoveaQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Lb5Mp4LI0] X-AnalysisOut: [xsA:10 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8 a=2l4Tx9zLCpAXCVJ] X-AnalysisOut: [QRIYA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8A] X-AnalysisOut: [:10 a=4sQnd5OqYV8Gp3D6:21 a=opkRbkVneGsXYqt8:21 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=BN6GY_yT30DcTn8vGjUA:9 a=gKO2Hq4] X-AnalysisOut: [RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=dIlyzRqZUAZzfHDq:21 a=OHjfXI0u7vx4eBQY:21 a=OxUVe3u] X-AnalysisOut: [NT3FECCv1:21] Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 18:35:17 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6113036E14CGAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_2D09D61DDFA73D4C884805CC7865E6113036E14CGAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First a process questi= on:

How detailed is this F= ramework document supposed to be? Is it intended to include the full list o= f criteria for a Control Protocol, or will these criteria be documented sep= arately? If the first, then I would prefer for the criteria to be more precisely described, and easy to identi= fy as Control Protocol criteria/requirements. If the latter, then I would p= refer for the Framework to use more descriptive language as to what is expe= cted of the Control Protocol, rather than trying to give names to all of the various expected functionality (e.= g., Instruction, registration). More detailed comments below.

Barbara

 

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Thursday, September 12, 2013 11:45 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions betwee= n MA and Controller

 

Thanks for the nice d= iscussion, I’ve tried to re-write to reflect where I think we’v= e got to. I also changed the title to:

 

Interactions between = MA and Controller

As part of a bootstra= p process the MA gets sufficient information to contact a Controller. Defin= ing a bootstrap mechanism is out of scope of the LMAP WG.=

 

The basic interaction= between a Controller and MA is that the Controller sends an Instruction to= the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect that= the measurement system understands what Measurement Methods the MA can do = and therefore the Controller can simply instruct the MA; there is no need f= or a negotiation protocol (which would add complexity to the MA, Controller and Control Protocol). However,= it is possible that the MA is in fact not capable of performing the reques= ted Measurement Method, and so the Control Protocol must allow the MA to re= ply with a suitable error code.

&n= bsp;

<bhs= > The use of the word “Instruction” here makes me uncomforta= ble, because it implies (at least to me) a manner of communication that is = not quite consistent with the way most WAN-based massive-number-of-controll= ed-devices control protocols work today. “Instruction” suggests a manner = of communication where the desired action is a part of the basic message. H= aving separate message syntax (actions) for everything the Controller wants= the MA to do would greatly increase the number of messages that need to go back and forth between MA and controller. This= sort of interaction is common in protocols intended to work on LAN segment= s. It’s a very bad idea for protocols intended to work over the WAN t= hat are intended to scale to large numbers of devices, and be highly extensible. I would prefer if we did not attempt= to give this function of the Controller to MA interaction a proper name (d= enoted by a capital first letter). I would also prefer if we described it a= s “the Controller configures the MA”, using the word “configure” instead of “instru= ct”.

&n= bsp;

I don&#= 8217;t think we’ve defined “negotiation protocol”. Probab= ly because we don’t need it. I would prefer if we got rid of that (ne= gotiation protocol) sentence and just used the last sentence as a positive statement about what we do expect from the Control Protocol. For example: = The Control Protocol must support robust error reporting by the MA, to prov= ide the Controller with sufficiently-detailed reasons for any failures in c= onfiguration.

&n= bsp;

Is R= 20;measurement system” defined? I’m a bit unclear on what this = is.

&n= bsp;

Resulti= ng recommended text:

The bas= ic interaction between a Controller and MA is that the Controller configures the MA, detailing what Measurement Tasks to do, when to do them= , and how to report the Measurement Results. In general we expect that the = Controller knows what Measurement Methods the MA supports, such that the Co= ntroller can correctly configure the MA. However, the Control Protocol must support robust error reporting = by the MA, to provide the Controller with sufficiently-detailed reasons for= any failures in configuration.

 

The MA can send to th= e Controller the list of Measurement Methods that it is capable of. This co= uld be useful:

[1] as part of the MA= registering with the Controller. Note that in some scenarios it is not nee= ded, as the Controller will know the information by other means, for example as part of the bootstrapping process (using Tr-069 say)= or because the MA is statically configured.

[2] so the MA can re-= register, for example if it becomes capable of a new Measurement Method.

** Comment: suggest w= e keep it simple and just send the complete list, rather than a delta. The = message should be short, since Methods are referred to via a registry.

[3] when requested by= the Controller, which could be useful if ‘something goes wrong’= ; and the Controller forgets what the MA can do.

&n= bsp;

<bhs= > The word “register” also makes me uncomfortable, though no= t as much as “Instruct”. This implies to me some very specific = functionality than I don’t consider completely necessary. But maybe if “registration” were defined I would feel better about it. T= he “**Comment” suggestion is too specific for the Framework, IM= O. But if Framework has detailed Control Protocol criteria, then I would re= word the statement as “The Control Protocol must allow the Controller to request the MA supply the MA’s complete list of suppor= ted Measurement Methods, in a concise format.”  I would prefer i= f the above statements were reworded as:

The MA = can send to the Controller the list of Measurement Methods that it is capable of. This could be useful:

[1] whe= n the MA first communicates with a Controller.

[2] whe= n the MA becomes capable of a new Measurement Method.

[3] whe= n requested by the Controller (e.g., if the Controller forgets what the MA can do or otherwise wants to resynchronize what it knows about= the MA).

 

Note that the advert = contains the list of Measurement Methods that the MA can perform. It is not= intended to indicate dynamic capabilities like the MA’s currently unused CPU, memory or battery life.

** Comment: I’m= not sure whether we reached consensus on this point.

&n= bsp;

<bhs= > I would have no objection to including such capabilities as optional e= lements of the information model. In fact, I think it would be a good idea.= But I don’t think this needs to be mentioned in the Framework.

It is possible that l= ater, when a MA is implementing the Instruction, it does not perform a part= icular Measurement Task for some reason, such as: the Measurement Peer is busy, or there is cross-traffic, … The MA doesn’t info= rm the Controller, instead it is reported to the Collector as part of the M= easurement Report. The Collector may in turn tell the measurement system or= even the Controller, but this is out of scope of LMAP.

** Comment: are there= any conditions when it’s critical for the Controller to be informed?=

&n= bsp;

<bhs= > Ditto my previous objection to “Instruction”. I believe th= e information model needs to include status parameters that would allow the= Controller to request this info, at some level. This can be optional to support for MA and Controller. I recommend rewording to:

It is p= ossible that an MA is unable to carry out a configured Measurement Task. Possible reasons include the Measurement Peer being busy, presence o= f cross-traffic, … The MA will report this information to the Collect= or as part of the Measurement Report. The Collector may in turn tell other = systems (including, possibly, the Controller), but this is out of scope of LMAP. The MA may also be able to inform the Co= ntroller directly of such occurrences.

&n= bsp;

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 05 September 2013 11:13
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 No negotiation between MA an= d Controller

 

Another issue:

There is no negotiati= on between the MA and Controller - the Controller simply sends the Instruct= ion to the MA, with the details of the Measurement Tasks to perform.

In general we expect = that the measurement system understands the capabilities of its MAs (probab= ly there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. It would also= add complexity to the MA, Controller and Control Protocol.

 

It is possible that t= he MA can’t perform the requested Measurement Task. So the Control Pr= otocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to se= nd a list of all the Measurement Methods that it is capable of, in case = 216;something goes wrong’ and the Controller forgets what the MA can = do. Comment: this idea hasn’t had much discussion yet, but appears in the Information Model i-d

 

Thoughts?

Thanks

phil

--_000_2D09D61DDFA73D4C884805CC7865E6113036E14CGAALPA1MSGUSR9L_-- From Michael.K.Bugenhagen@centurylink.com Thu Sep 12 11:46:55 2013 Return-Path: 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 6CCC221E8203 for ; Thu, 12 Sep 2013 11:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 P0tXYe9yRgnT for ; Thu, 12 Sep 2013 11:46:46 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4495811E8211 for ; Thu, 12 Sep 2013 11:46:37 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r8CIkS4W029184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 13:46:28 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 3DF9D1E0059; Thu, 12 Sep 2013 13:46:23 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 010CA1E0066; Thu, 12 Sep 2013 13:46:22 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r8CIkMjm006062; Thu, 12 Sep 2013 12:46:22 -0600 (MDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r8CIkLRJ006053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 12:46:22 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.02.0318.001; Thu, 12 Sep 2013 13:46:22 -0500 From: "Bugenhagen, Michael K" To: "'philip.eardley@bt.com'" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAAG+txQ Date: Thu, 12 Sep 2013 18:46:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E047BD352podcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 18:46:55 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E047BD352podcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, IMHO the MA's should be generating a "test results log" which is a short= abbreviated log of tests to send to the Test Controller. It's NOT a wonderful thing to think all is well in the world only to find= out at the end of the month that all your test results are filled with zer= os. So maybe a happy / sad indicator on the test scheduler would be a good thin= g To do so 1) MA would have to make a log of things like a. Test ID (should be unique) b. From point xxx c. To point yyy d. Test type zzz e. KPI result - pick anything that shouldn't be a zero f. Test closure condition - abort, normal, test refused, couldn't ru= n test This way we have information to figure out why schedule testing is or more = importantly is not running as desired, what our failure rates are, and if w= e're collecting a bunch of zero's or not. Cheers, Mike From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: Thursday, September 12, 2013 10:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_A68F3CAC468B2E48BB775ACE2DD99B5E047BD352podcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil,

 

   IMHO the = MA’s should be generating a “test results log” which is a= short abbreviated log of tests to send to the Test Controller.<= /span>

  It’s NOT = a wonderful thing to think all is well in the world only to find out at the= end of the month that all your test results are filled with zeros.

 

So maybe a happy / sad= indicator on the test scheduler would be a good thing

 

To do so

 

1)&n= bsp;     MA would have = to make a log of things like

a. &nbs= p;     Test ID (shoul= d be unique)

b. &nbs= p;    From point xxx=

c. &nbs= p;     To point yyy

d. &nbs= p;    Test type zzz<= o:p>

e. &nbs= p;    KPI result = 211; pick anything that shouldn’t be a zero

f. &nbs= p;      Test closure c= ondition – abort, normal, test refused, couldn’t run test<= /o:p>

 

This way we have infor= mation to figure out why schedule testing is or more importantly is not run= ning as desired, what our failure rates are, and if we’re collecting = a bunch of zero’s or not.

 

Cheers,

Mike=

 

 

 

 

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Thursday, September 12, 2013 10:45 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions betwee= n MA and Controller

 

Thanks for the nice d= iscussion, I’ve tried to re-write to reflect where I think we’v= e got to. I also changed the title to:

 

Interactions between = MA and Controller

As part of a bootstra= p process the MA gets sufficient information to contact a Controller. Defin= ing a bootstrap mechanism is out of scope of the LMAP WG.=

 

The basic interaction= between a Controller and MA is that the Controller sends an Instruction to= the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect that= the measurement system understands what Measurement Methods the MA can do = and therefore the Controller can simply instruct the MA; there is no need f= or a negotiation protocol (which would add complexity to the MA, Controller and Control Protocol). However,= it is possible that the MA is in fact not capable of performing the reques= ted Measurement Method, and so the Control Protocol must allow the MA to re= ply with a suitable error code.

 

The MA can send to th= e Controller the list of Measurement Methods that it is capable of. This co= uld be useful:

[1] as part of the MA= registering with the Controller. Note that in some scenarios it is not nee= ded, as the Controller will know the information by other means, for example as part of the bootstrapping process (using Tr-069 say)= or because the MA is statically configured.

[2] so the MA can re-= register, for example if it becomes capable of a new Measurement Method.

** Comment: suggest w= e keep it simple and just send the complete list, rather than a delta. The = message should be short, since Methods are referred to via a registry.

[3] when requested by= the Controller, which could be useful if ‘something goes wrong’= ; and the Controller forgets what the MA can do.

 

Note that the advert = contains the list of Measurement Methods that the MA can perform. It is not= intended to indicate dynamic capabilities like the MA’s currently unused CPU, memory or battery life.

** Comment: I’m= not sure whether we reached consensus on this point.

 

It is possible that l= ater, when a MA is implementing the Instruction, it does not perform a part= icular Measurement Task for some reason, such as: the Measurement Peer is busy, or there is cross-traffic, … The MA doesn’t info= rm the Controller, instead it is reported to the Collector as part of the M= easurement Report. The Collector may in turn tell the measurement system or= even the Controller, but this is out of scope of LMAP.

** Comment: are there= any conditions when it’s critical for the Controller to be informed?=

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 05 September 2013 11:13
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 No negotiation between MA an= d Controller

 

Another issue:

There is no negotiati= on between the MA and Controller - the Controller simply sends the Instruct= ion to the MA, with the details of the Measurement Tasks to perform.

In general we expect = that the measurement system understands the capabilities of its MAs (probab= ly there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. It would also= add complexity to the MA, Controller and Control Protocol.

 

It is possible that t= he MA can’t perform the requested Measurement Task. So the Control Pr= otocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to se= nd a list of all the Measurement Methods that it is capable of, in case = 216;something goes wrong’ and the Controller forgets what the MA can = do. Comment: this idea hasn’t had much discussion yet, but appears in the Information Model i-d

 

Thoughts?

Thanks

phil

--_000_A68F3CAC468B2E48BB775ACE2DD99B5E047BD352podcwmbxex505ct_-- From marcelo@it.uc3m.es Fri Sep 13 02:47:04 2013 Return-Path: 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 A2D5121F9E9A for ; Fri, 13 Sep 2013 02:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 LHhwl4+1n5rv for ; Fri, 13 Sep 2013 02:46:59 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5C421F9E6B for ; Fri, 13 Sep 2013 02:46:59 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5AE8CFA973F for ; Fri, 13 Sep 2013 11:46:58 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost17.it.uc3m.es (unknown [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 45520FA96F2 for ; Fri, 13 Sep 2013 11:46:58 +0200 (CEST) Message-ID: <5232DF11.3080908@it.uc3m.es> Date: Fri, 13 Sep 2013 11:46:57 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lmap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Fri, 13 Sep 2013 11:46:58 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20146.005 X-TM-AS-Result: No--25.485-7.0-31-1 X-imss-scan-details: No--25.485-7.0-31-1 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 09:47:04 -0000 Hi Phil, Good stuff, thanks for doing this. A couple of comments below... (hopefully nits that will give us some flexibility later on) El 12/09/13 17:44, philip.eardley@bt.com escribió: > > Thanks for the nice discussion, I’ve tried to re-write to reflect > where I think we’ve got to. I also changed the title to: > > Interactions between MA and Controller > > As part of a bootstrap process the MA gets sufficient information to > contact a Controller. Defining a bootstrap mechanism is out of scope > of the LMAP WG. > > The basic interaction between a Controller and MA is that the > Controller sends an Instruction to the MA, detailing what Measurement > Tasks to do, when to do them, and how to report the Measurement > Results. In general we expect that the measurement system understands > what Measurement Methods the MA can do and therefore the Controller > can simply instruct the MA; there is no need for a negotiation > protocol (which would add complexity to the MA, Controller and Control > Protocol). However, it is possible that the MA is in fact not capable > of performing the requested Measurement Method, and so the Control > Protocol must allow the MA to reply with a suitable error code. > mmmm, I would rephrase the last sentence as follows: The control protocol must allow the controller to learn that the MA was unable to perform the requested measurement method and some error code describing why. I am suggesting this because as it is currently phrased, it seems that the control protocol needs to have a inmediate reply with the error, which is not what is covered in the information model, i think. In the information model, we have a logging and status information that can be queried where this information lies, but it is not returned as a response to an instruction. > The MA can send to the Controller the list of Measurement Methods that > it is capable of. This could be useful: > I would rephrase as: "the controller can retrieve from the MA the list of measurement methods..." the way it is currnelty written it seems the MA will spontaneously send the information to the controller > [1] as part of the MA registering with the Controller. Note that in > some scenarios it is not needed, as the Controller will know the > information by other means, for example as part of the bootstrapping > process (using Tr-069 say) or because the MA is statically configured. > > [2] so the MA can re-register, for example if it becomes capable of a > new Measurement Method. > > ** Comment: suggest we keep it simple and just send the complete list, > rather than a delta. The message should be short, since Methods are > referred to via a registry. > > [3] when requested by the Controller, which could be useful if > ‘something goes wrong’ and the Controller forgets what the MA can do. > > Note that the advert contains the list of Measurement Methods that the > MA can perform. It is not intended to indicate dynamic capabilities > like the MA’s currently unused CPU, memory or battery life. > > ** Comment: I’m not sure whether we reached consensus on this point. > > It is possible that later, when a MA is implementing the Instruction, > it does not perform a particular Measurement Task for some reason, > such as: the Measurement Peer is busy, or there is cross-traffic, … > The MA doesn’t inform the Controller, instead it is reported to the > Collector as part of the Measurement Report. > mmm, i would also mention that the MA may have a logging capability to store additional information about such events. regards, marcelo > The Collector may in turn tell the measurement system or even the > Controller, but this is out of scope of LMAP. > > ** Comment: are there any conditions when it’s critical for the > Controller to be informed? > > *From:*lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] *On Behalf > Of *philip.eardley@bt.com > *Sent:* 05 September 2013 11:13 > *To:* lmap@ietf.org > *Subject:* [lmap] LMAP Framework issue #3 No negotiation between MA > and Controller > > Another issue: > > There is no negotiation between the MA and Controller - the Controller > simply sends the Instruction to the MA, with the details of the > Measurement Tasks to perform. > > In general we expect that the measurement system understands the > capabilities of its MAs (probably there are only one or a few classes > of MA), so negotiation about the MA’s capabilities would have little > benefit. It would also add complexity to the MA, Controller and > Control Protocol. > > It is possible that the MA can’t perform the requested Measurement > Task. So the Control Protocol needs to allow the MA to reply with an > error code. It has also been suggested that the Controller should be > able to ask the MA to send a list of all the Measurement Methods that > it is capable of, in case ‘something goes wrong’ and the Controller > forgets what the MA can do. Comment: this idea hasn’t had much > discussion yet, but appears in the Information Model i-d > > Thoughts? > > Thanks > > phil > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From marcelo@it.uc3m.es Fri Sep 13 02:50:25 2013 Return-Path: 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 820E721F9FB6 for ; Fri, 13 Sep 2013 02:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 KjbVgxSjO+hb for ; Fri, 13 Sep 2013 02:50:20 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 958A121F9E96 for ; Fri, 13 Sep 2013 02:50:17 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 397C4CC5DEF for ; Fri, 13 Sep 2013 11:50:16 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost17.it.uc3m.es (unknown [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 2AF42CB7E6C for ; Fri, 13 Sep 2013 11:50:16 +0200 (CEST) Message-ID: <5232DFD7.60100@it.uc3m.es> Date: Fri, 13 Sep 2013 11:50:15 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lmap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Fri, 13 Sep 2013 11:50:16 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20146.005 Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 09:50:25 -0000 Hi Phil, one comment below... El 12/09/13 18:40, philip.eardley@bt.com escribió: > > Thanks for the great discussion about this point as well. again I > adjusted the title. I think we converged on this issue – well let’s > see if I’m wrong! > > Starting and stopping Measurement Tasks > > Many Active Measurement Tasks begin with a pre-check before the test > traffic is sent. Action could include: > > * the MA checking that there is no cross-traffic (ie that the user > isn’t already sending traffic); > > * the MA checking with the Measurement Peer that it can handle a new > Measurement Task (in case the MP is already handling many Measurement > Tasks with other MAs); > > * the first part of the Measurement Task consisting of traffic that > probes the path to make sure it isn’t overloaded. > > It is possible that similar checks continue during the Measurement > Task, especially one that is long-running &/or creates a lot of > traffic, and it is abandoned whilst in-progress. Action could include: > > ·For ‘upload’ tests, the MA not sending traffic > > ·For ‘download’ tests, the MA closing the TCP connection or sending a > TWAMP Stop control message. > > If there is some unexpected network issue, the measurement system may > want to eliminate inessential traffic. Therefore the Controller has > the ability to send a “suppress” message to MAs. As a result, > temporarily the MA does not start new Active Measurement Tasks, and it > may also stop in-progress Measurement Tasks, especially ones that are > long-running &/or creates a lot of traffic. > > The LMAP WG does not define a generic start and stop process, since > the correct approach depend on the particular Measurement Task; > i think that the last exchange with Al we converged to: - lmap will define a generic mechanism to inform from the controller to the MA that the current and ongoing tests are to be stopped. - the actuall messages and actions that need to happen in order to actually do this depends on the specific test, hence out of the scope for lmap regards, marcelo > the details are defined as part of each Measurement Method, and hence > potentially by the IPPM WG. This also means that the LMAP framework > doesn’t define a coordination process between MAs; whilst a > measurement system may define coordinated Measurement Schedules across > its various MAs, there is no direct coordination between MAs. > > The MA does not inform the Controller about Measurement Tasks starting > or stopping. The Measurement Report includes the start and end of > suppression, and it labels (or perhaps doesn’t include) Measurement > Results impacted by for instance cross-traffic. > > *From:*lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] *On Behalf > Of *philip.eardley@bt.com > *Sent:* 03 September 2013 18:23 > *To:* lmap@ietf.org > *Subject:* [lmap] LMAP Framework issue #2 Admission control and > measurement suppression > > Another issue…. > > Admission control functionality pre-checks that it is a suitable > moment to carry out a Measurement Task. It is the job of the > Measurement Method to define such a pre-check – hence this is in the > scope of IPPM rather than LMAP. Action could include: > > * the MA checking that there is no cross-traffic (ie that the user > isn’t already sending traffic) before the Measurement Task starts > sending traffic; > > * the first part of the Measurement Task consisting of the MA asking > the Measurement Peer whether it can send test traffic; > > * the first part of the Measurement Task consisting of traffic that > probes the path to make sure it isn’t overloaded; > > * the Measurement Task detecting the presence of cross-traffic after > the MA (&/or MP) has started sending traffic. > > Note that the LMAP WG does not define a generic admission control > process, since the correct approach depends on the particular > Measurement Task. This also means that the framework doesn’t define a > coordination process between MAs; whilst a measurement system may > define coordinated Measurement Schedules across its various MAs, there > is no direct coordination between MAs. > > In addition the Controller may want to send a “suppress” message to > some MAs so that they temporarily stop performing Active Measurement > Tasks – perhaps there is some unexpected network issue and the ISP > wants to eliminate inessential traffic. Since some Measurement Tasks > involve the MP sending traffic to the MA, so this suggests the MA may > sometimes need to send a “suppress” message to the MP. > > Discussion needed… > > 1. the Broadband Forum liaison mentioned a generic admission process, > but my impression is that people no longer think this is needed. Just > wanted to make sure I got that right. > > 2. I’ve heard a couple of comments that suppression is needed, but we > haven’t had much discussion – do people agree? > > 3. the Information Model should discuss how suppression gets recorded > in the results (perhaps the on-going results get scrapped – perhaps > the results are marked with a warning – perhaps it depends on the metric?) > > 4. suppress is a bit messy if the MP is sending traffic to the MA (eg > download speed test). One MP may be sending to several MAs. perhaps > the suppress msg should go directly to the MP? Of course if the MP > doesn’t have lmap functionality then there’s nothing that can be done > in any case. > > Comments? > > Thanks > > phil > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Fri Sep 13 09:32:38 2013 Return-Path: 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 409C121E80AE for ; Fri, 13 Sep 2013 09:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 CrN-Cw0nisVN for ; Fri, 13 Sep 2013 09:32:33 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2547021E8105 for ; Fri, 13 Sep 2013 09:32:27 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 13 Sep 2013 17:32:26 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Fri, 13 Sep 2013 17:32:26 +0100 From: To: , Date: Fri, 13 Sep 2013 17:31:19 +0100 Thread-Topic: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks Thread-Index: Ac6wZq5ezKRgvvWpSFqTHdqYBARGQwAN/6r3 Message-ID: References: , <5232DFD7.60100@it.uc3m.es> In-Reply-To: <5232DFD7.60100@it.uc3m.es> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:32:38 -0000 i think that the last exchange with Al we converged to: - lmap will define a generic mechanism to inform from the controller to the MA that the current and ongoing tests are to be stopped. - the actuall messages and actions that need to happen in order to actually do this depends on the specific test, hence out of the scope for lmap [phil] that's what i meant - the way you put it is clearer!= From sharam.hakimi@exfo.com Fri Sep 13 10:38:28 2013 Return-Path: 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 7EF4E21F9FD5 for ; Fri, 13 Sep 2013 10:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 hQt0Lyae4cwm for ; Fri, 13 Sep 2013 10:38:21 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 68DEB21F9F2D for ; Fri, 13 Sep 2013 10:38:18 -0700 (PDT) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Sep 2013 13:38:13 -0400 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Sep 2013 13:38:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Sep 2013 13:28:33 -0400 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02804CA0@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks Thread-Index: Ac6wZq5ezKRgvvWpSFqTHdqYBARGQwAN/6r3AAG/g/A= References: , <5232DFD7.60100@it.uc3m.es> From: "Sharam Hakimi" To: , , X-OriginalArrivalTime: 13 Sep 2013 17:38:12.0582 (UTC) FILETIME=[05096860:01CEB0A8] Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 17:38:31 -0000 Is the assumption here for all MAs under a controller control, and not MAs under user control. MAs under user control would not necessarily respond to this command. Sharam -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Friday, September 13, 2013 12:31 PM To: marcelo@it.uc3m.es; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks i think that the last exchange with Al we converged to: - lmap will define a generic mechanism to inform from the controller to the MA that the current and ongoing tests are to be stopped. - the actuall messages and actions that need to happen in order to actually do this depends on the specific test, hence out of the scope for lmap [phil] that's what i meant - the way you put it is clearer! _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From acmorton@att.com Fri Sep 13 11:11:33 2013 Return-Path: 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 C430421E811F for ; Fri, 13 Sep 2013 11:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.742 X-Spam-Level: X-Spam-Status: No, score=-106.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0ncs5h6rco5r for ; Fri, 13 Sep 2013 11:11:28 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id A407D11E8166 for ; Fri, 13 Sep 2013 11:11:28 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 03A88120D39; Fri, 13 Sep 2013 14:11:27 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id 054D3E010F; Fri, 13 Sep 2013 14:11:06 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::a44a:8177:9a5d:ac00%15]) with mapi; Fri, 13 Sep 2013 14:11:28 -0400 From: "MORTON, ALFRED C (AL)" To: "philip.eardley@bt.com" , "marcelo@it.uc3m.es" , "lmap@ietf.org" Date: Fri, 13 Sep 2013 14:11:26 -0400 Thread-Topic: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks Thread-Index: Ac6wZq5ezKRgvvWpSFqTHdqYBARGQwAN/6r3AAM+B5A= Message-ID: <2845723087023D4CB5114223779FA9C8AAC2157F@njfpsrvexg8.research.att.com> References: , <5232DFD7.60100@it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:11:33 -0000 Editing the second point slightly, if I may: - the actual messages and actions needed to do this depends on the specific test, hence are unspecified by LMAP ^^^^^^^^^^^^^^^^^^^^^^^ (we expect the scope of LMAP's control to include actions in=20 the test protocol, but we leave it to those protocols to=20 do what they can to abort a test) Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: Friday, September 13, 2013 12:31 PM > To: marcelo@it.uc3m.es; lmap@ietf.org > Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and stoppin= g > Measurement Tasks >=20 > i think that the last exchange with Al we converged to: > - lmap will define a generic mechanism to inform from the controller to > the MA that the current and ongoing tests are to be stopped. > - the actuall messages and actions that need to happen in order to > actually do this depends on the specific test, hence out of the scope > for lmap >=20 > [phil] that's what i meant - the way you put it is clearer! > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From david.sinicrope@ericsson.com Thu Sep 12 09:57:33 2013 Return-Path: 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 C897621E814D; Thu, 12 Sep 2013 09:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.598 X-Spam-Level: X-Spam-Status: No, score=-104.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 1CYZOn3dKmQ1; Thu, 12 Sep 2013 09:57:20 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCF321E80FC; Thu, 12 Sep 2013 09:57:19 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-d4-5231f26e6d1f Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4C.52.03458.E62F1325; Thu, 12 Sep 2013 18:57:18 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Thu, 12 Sep 2013 12:57:17 -0400 From: David Sinicrope To: "Weil, Jason" , "lmap@ietf.org" , "ippm@ietf.org" Thread-Topic: [lmap] Liaison reply to Broadband Forum liaisons Thread-Index: AQHOr9kiiLGv9MPPXUCfdVl4dOGL8A== Date: Thu, 12 Sep 2013 16:57:17 +0000 Message-ID: <871EB8879748FA458598F046190628931C25F61C@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_871EB8879748FA458598F046190628931C25F61Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyuXRPgm7eJ8Mgg0PHLSyOnOlgtZjZ84/R 4tLT/YwWPQ/eMVvM2LeCzWLG7H2MFl//dbBYNJ/Xtph24AGTxaeu56wOXB5zFt1m9JjyeyOr x85Zd9k9liz5yeQx8/gXFo8Tc+cxeWxdMp3N4/60iUweq9e8YgngjOKySUnNySxLLdK3S+DK eP37NGvB9dyKE+veMTYwTozrYuTkkBAwkTi06AUThC0mceHeerYuRi4OIYGjjBJnH0EkhASW M0ocXKIFYrMBNazbuIeli5GDQ0QgT2JqQxpIPbPAXiaJTZengdULC9hKTPi/gw3EFhGwk/jT 8ZEVwtaTuHHsE1icRUBVYt/d+YwgNq+Ar0THxBNgNZxA8x/O7gCbwwh00PdTa8BsZgFxiVtP 5kMdKiCxZM95ZghbVOLl439gvaJA89e374aqUZZY8mQ/C0RvvsTxCTPZIHYJSpyc+YRlAqPo LCRjZyEpm4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxrif5vh1iQ1Sxg5FjFyFFanFqW m25kuIkRmACOSbA57mBc8MnyEKM0B4uSOO8GvTOBQgLpiSWp2ampBalF8UWlOanFhxiZODil GhhNrH6v4DjkcaeqMvb9rjwDfQe2OIW4xYaLzvzrvHz2z1rZBd0CG7e0R63uyv/QHenSvDZK Zray575DJuulekvi587T9otomzCh6+eqJdZLt18R0Hjqv6l5WbNDT8JM9wcSXzb3Rc+d/7nB NXCa5frNfNvyMu5Kad3YYLtyM2eeF1+08LWVnK1KLMUZiYZazEXFiQAM1yv1zgIAAA== X-Mailman-Approved-At: Sun, 15 Sep 2013 08:15:58 -0700 Cc: "brian@innovationslab.net" , David Sinicrope , Eliot Lear , "mark@townsley.net" , "ray.bellis@nominet.org.uk" , Alissa Cooper , "jari.arkko@piuha.net" Subject: Re: [lmap] Liaison reply to Broadband Forum liaisons X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:57:33 -0000 --_000_871EB8879748FA458598F046190628931C25F61Ceusaamb103erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jason, Sorry for the very late response. Yes, these items are still outstanding i= n their current wording. The December 2012 liaison was addressed to IPPM and the Transport Ads. It = may be more appropriate for IPPM to respond. Based on some of the LMAP list comments, some of the information requested = may also have more to do with Homenet. I'd be happy to work with the Chairs of the respective working groups to co= me up with a single response back to the BBF. Thanks, Dave From: , Jason > Date: Monday, August 5, 2013 3:45 PM To: David A Sinicrope >, "lmap@ietf.org" > Cc: Alissa Cooper >, Eliot Lear >, David A Sinicrope > Subject: Re: [lmap] Liaison reply to Broadband Forum liaisons David, Here are the actionable items from my reading of the March 2013 and Decembe= r 2012 Broadband Forum liaison letters. Is it safe to assume these items ar= e still outstanding in their current wording? BBF March 2013 letter actionable items: 1. Feedback on the use of SIP to provide an inter and intra domain mecha= nism to probe test target resource availability. 2. Comments on the use of DNS-SD(RFC6763) and mDNS (RFC6762) to support = BBF's service attribute communication. 3. Information model development for test and report parameters BBF December 2012 letter actionable items: (The majority of these items fal= l into the IPPM WG but BMWG items are also referenced) 1. Questions on RFC3148 - IPPM 2. Questions on RFC6349 - IPPM 3. Alternatives to RFC3148 and RFC6349 - IPPM 4. Comments on the use of RFC2681, RFC3393, and RFC2680 metrics =96 IPPM 5. RFC2544 =96 BMWG (also see RFC6815) 6. Any IETF solutions for measuring real-time and near real-time applica= tions traffic as well as DNS resolution time. Thanks, Jason From: David Sinicrope > Date: Wednesday, July 31, 2013 2:11 PM To: "lmap@ietf.org" > Cc: Alissa Cooper >, Eliot Lear >, David Sinicrope > Subject: [lmap] Liaison reply to Broadband Forum liaisons Hi All, As I mentioned at the mike yesterday there seems to be potential for overla= p between some of the LMAP work (e.g., framework, terminology, etc.) and th= e "Broadband Access Service Attributes and Performance Metrics" (WT-304) wo= rk going on in the Broadband Forum (BBF). There are also several unanswered liaisons from Broadband Forum to the IETF= dating back to last August before LMAP was formed. (See list below) Some = of these have detailed content from the BBF draft document and questions th= at the LMAP WG should respond to. To support coordination and cooperation between the BBF and IETF LMAP, to e= nsure we don't duplicate work, and to request the latest version of the BBF= work, it would be advantageous to respond to the BBF liaisons and question= s now that the LMAP WG has been formed and there is a charter, scope of wor= k and initial work on documents. Thanks, Dave Sinicrope Ericsson IETF Liaison Manager to the Broadband Forum Mar 2013 - https://datatracker.ietf.org/liaison/1243/ Dec 2012 - https://datatracker.ietf.org/liaison/1221/ Sep 2012 - https://datatracker.ietf.org/liaison/1185/ Aug 2012 - https://datatracker.ietf.org/liaison/1179/ ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_871EB8879748FA458598F046190628931C25F61Ceusaamb103erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: <39743624865A1F469641F0D68BE976B7@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Jason,
Sorry for the very late response.  Yes, these items are still out= standing in their current wording.

The December 2012 liaison was addressed to IPPM and the Transport Ads.=  It may be more appropriate for IPPM to respond.
Based on some of the LMAP list comments, some of the information reque= sted may also have more to do with Homenet.

I'd be happy to work with the Chairs of the respective working groups = to come up with a single response back to the BBF.

Thanks,
Dave




From: <Weil>, Jason <jason.weil@twcable.com>
Date: Monday, August 5, 2013 3:45 P= M
To: David A Sinicrope <david.sinicrope@gmail.com>, &q= uot;lmap@ietf.org" <lmap@ietf.org>
Cc: Alissa Cooper <acooper@cdt.org>, Eliot Lear <lear@cisco.com>, David A Sinicrope <david.sinicrope@ericsson.com&g= t;
Subject: Re: [lmap] Liaison reply t= o Broadband Forum liaisons

David,

Here are the actionable items from my reading of the March 2013 and De= cember 2012 Broadband Forum liaison letters. Is it safe to assume these ite= ms are still outstanding in their current wording? 

BBF March 2013 letter actionable items:
  1. Feedback on the use of SIP to provide an inter and intra domain mechani= sm to probe test target resource availability. 
  2. Comments on th= e use of DNS-SD(RFC6763) and mDNS (RFC6762) to support BBF's service attrib= ute communication.   
  3. Information model development for t= est and report parameters
BBF December 2012 letter actionable items: (The majority of these item= s fall into the IPPM WG but BMWG items are also referenced)
  1. Questions on RFC3148 - IPPM
  2. Questions on RFC6349 - IPPM
    3. Alternatives to RFC3148 and RFC6349 - IPPM
  3. Comments on the use of = RFC2681, RFC3393, and RFC2680 metrics =96 IPPM
  4. RFC2544 =96 BMWG (al= so see RFC6815)
  5. Any IETF solutions for measuring real-time and near= real-time applications traffic as well as DNS resolution time.
Thanks,

Jason

From: David Sinicrope <david.sinicrope@gmail.com>
Date: Wednesday, July 31, 2013 2:11= PM
To: "lmap@ietf.org" <lmap@i= etf.org>
Cc: Alissa Cooper <acooper@cdt.org>, Eliot Lear <lear@cisco.com>, David Sinicrope <david.sinicrope@ericsson.com><= br> Subject: [lmap] Liaison reply to Br= oadband Forum liaisons

Hi All,
As I mentioned at the mike= yesterday there seems to be potential for overlap between some of the LMAP= work (e.g., framework, terminology, etc.) and the "Broadband Access Service Attributes and Performance Metrics" (WT-304) work goin= g on in the Broadband Forum (BBF).   

There are also several unan= swered liaisons from Broadband Forum to the IETF dating back to last August= before LMAP was formed.  (See list below) Some of these have detailed content from the BBF draft document and= questions that the LMAP WG should respond to.

To support coordination and= cooperation between the BBF and IETF LMAP, to ensure we don't duplicate wo= rk, and to request the latest version of the BBF work, it would be advantageous to respond to the BBF liaisons a= nd questions now that the LMAP WG has been formed and there is a charter, s= cope of work and initial work on documents.

Thanks,
Dave Sinicrope
Ericsson
IETF Liaison Manager to the Broadband Forum





This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_871EB8879748FA458598F046190628931C25F61Ceusaamb103erics_-- From trevor.burbridge@bt.com Mon Sep 16 01:04:24 2013 Return-Path: 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 CF64C11E81E8 for ; Mon, 16 Sep 2013 01:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] 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 47POw8jvdWxN for ; Mon, 16 Sep 2013 01:04:15 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8F711E8102 for ; Mon, 16 Sep 2013 01:04:14 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 16 Sep 2013 09:04:12 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 16 Sep 2013 09:04:11 +0100 From: To: , , , Date: Mon, 16 Sep 2013 09:04:10 +0100 Thread-Topic: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks Thread-Index: Ac6wZq5ezKRgvvWpSFqTHdqYBARGQwAN/6r3AAG/g/AAg1BaoA== Message-ID: References: , <5232DFD7.60100@it.uc3m.es> <084CDC75FEC1E640B60338273BEACDFA02804CA0@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02804CA0@spboexc01.exfo.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 08:04:24 -0000 >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >Sharam Hakimi >Sent: 13 September 2013 18:29 >To: Eardley,PL,Philip,TUB8 R; marcelo@it.uc3m.es; lmap@ietf.org >Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping >Measurement Tasks > >Is the assumption here for all MAs under a controller control, and not >MAs under user control. MAs under user control would not necessarily >respond to this command. It would be the same. The user may have scheduled long-term tests that they= want to temporarily suppress. >Sharam > >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >philip.eardley@bt.com >Sent: Friday, September 13, 2013 12:31 PM >To: marcelo@it.uc3m.es; lmap@ietf.org >Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and >stopping Measurement Tasks > >i think that the last exchange with Al we converged to: >- lmap will define a generic mechanism to inform from the controller to >the MA that the current and ongoing tests are to be stopped. >- the actuall messages and actions that need to happen in order to >actually do this depends on the specific test, hence out of the scope >for lmap > >[phil] that's what i meant - the way you put it is clearer! >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From Michael.K.Bugenhagen@centurylink.com Mon Sep 16 07:43:52 2013 Return-Path: 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 6778911E8299 for ; Mon, 16 Sep 2013 07:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] 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 JSlije9C8cDb for ; Mon, 16 Sep 2013 07:43:44 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2044411E8298 for ; Mon, 16 Sep 2013 07:43:36 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r8GEhVuL018205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Sep 2013 09:43:31 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id D10CB1E0058; Mon, 16 Sep 2013 09:43:25 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id B02021E0049; Mon, 16 Sep 2013 09:43:25 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r8GEhPhX004990; Mon, 16 Sep 2013 09:43:25 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r8GEhPaw004987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Sep 2013 09:43:25 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.02.0318.001; Mon, 16 Sep 2013 09:43:25 -0500 From: "Bugenhagen, Michael K" To: "'trevor.burbridge@bt.com'" , "sharam.hakimi@exfo.com" , "philip.eardley@bt.com" , "marcelo@it.uc3m.es" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks Thread-Index: AQHOsrPIP8IrdGMVLkiGm7Q/G6gBv5nIcFCw Date: Mon, 16 Sep 2013 14:43:23 +0000 Message-ID: References: , <5232DFD7.60100@it.uc3m.es> <084CDC75FEC1E640B60338273BEACDFA02804CA0@spboexc01.exfo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 14:43:52 -0000 I agree with a "red light" command to push out to MA's. But this also suggests we need a green light to allow testing, and since we= 're on the topic is there any such use case where a yellow light might be w= ise (say I know there's problems so I don't want to throughput test, but I = do want to do OAM, and passive testing) ? -M -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of tre= vor.burbridge@bt.com Sent: Monday, September 16, 2013 3:04 AM To: sharam.hakimi@exfo.com; philip.eardley@bt.com; marcelo@it.uc3m.es; lmap= @ietf.org Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and stopping = Measurement Tasks >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of=20 >Sharam Hakimi >Sent: 13 September 2013 18:29 >To: Eardley,PL,Philip,TUB8 R; marcelo@it.uc3m.es; lmap@ietf.org >Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and=20 >stopping Measurement Tasks > >Is the assumption here for all MAs under a controller control, and not=20 >MAs under user control. MAs under user control would not necessarily=20 >respond to this command. It would be the same. The user may have scheduled long-term tests that they= want to temporarily suppress. >Sharam > >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of=20 >philip.eardley@bt.com >Sent: Friday, September 13, 2013 12:31 PM >To: marcelo@it.uc3m.es; lmap@ietf.org >Subject: Re: [lmap] LMAP Framework issue #2 (take 2) Starting and=20 >stopping Measurement Tasks > >i think that the last exchange with Al we converged to: >- lmap will define a generic mechanism to inform from the controller to=20 >the MA that the current and ongoing tests are to be stopped. >- the actuall messages and actions that need to happen in order to=20 >actually do this depends on the specific test, hence out of the scope=20 >for lmap > >[phil] that's what i meant - the way you put it is clearer! >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Tue Sep 17 02:59:23 2013 Return-Path: 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 5872A11E83CF for ; Tue, 17 Sep 2013 02:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.069 X-Spam-Level: X-Spam-Status: No, score=-103.069 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_40=-0.185, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 UlOwCLgPlw+d for ; Tue, 17 Sep 2013 02:59:07 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAF211E80F3 for ; Tue, 17 Sep 2013 02:59:05 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 17 Sep 2013 10:58:57 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Tue, 17 Sep 2013 10:58:57 +0100 From: To: , Date: Tue, 17 Sep 2013 10:58:55 +0100 Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518905EMV67UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 09:59:23 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518905EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Barbara. thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. Not sure I fully understood your point about Instruction. I was trying to use it as defined in the terminology <> The Instruction would be a message with - one of more Measurement Tasks - one of more Schedules - one or more Report Channels I guess the first msg from Controller to MA includes all of these. Subseque= nt msgs might only update one of them, for instance the Schedule might get = updated rather more often than the other two items. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 12 September 2013 19:34 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518905EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Barbara= .

thinking about your process q= uestion – we’re now trying to write a ‘protocol modelR= 17; for the framework doc (rfc4101) – so the protocol will be describ= ed at this level.

 <= /o:p>

Not sure I fully understood your poi= nt about Instruction.

I was try= ing to use it as defined in the terminology

<<In=
struction: The description of Measurement Tasks to perform and the

 &nbs= p; details of the Report to send.  The Instruction is sent by a

 &nbs= p; Controller to a Measurement Agent.

>> 

<= span lang=3DEN style=3D'font-size:12.0pt;font-family:"Arial","sans-serif";c= olor:blue'> 

The= Instruction would be a message with

-       one of more Measurement Tasks

-    =    one of more Schedul= es

- =       o= ne or more Report Channels

I guess the first msg from Controller to MA includes all of these. Su= bsequent msgs might only update one of them, for instance the Schedule migh= t get updated rather more often than the other two items.

 

          =             &nb= sp;            =             &nb= sp;            =         

From: STARK, = BARBARA H [mailto:bs7652@att.com]
Sent: 12 September 2013 19:34<= br>To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE= : [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Contr= oller

 

First= a process question:

How detailed is this Framework document su= pposed to be? Is it intended to include the full list of criteria for a Con= trol Protocol, or will these criteria be documented separately? If the firs= t, then I would prefer for the criteria to be more precisely described, and= easy to identify as Control Protocol criteria/requirements. If the latter,= then I would prefer for the Framework to use more descriptive language as = to what is expected of the Control Protocol, rather than trying to give nam= es to all of the various expected functionality (e.g., Instruction, registr= ation). More detailed comments below.

Barbara

&nbs= p;

From:= lmap-bounces@ietf= .org [mailto:lmap-bounces@ietf= .org] On Behalf Of phil= ip.eardley@bt.com
Sent: Thursday, September 12, 2013 11:45 AM=
To: lmap@ietf.org
Sub= ject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA a= nd Controller

 

Thanks for the nic= e discussion, I’ve tried to re-write to reflect where I think we̵= 7;ve got to. I also changed the title to:

 

Interactions between MA a= nd Controller

As part of a bootstrap = process the MA gets sufficient information to contact a Controller. Definin= g a bootstrap mechanism is out of scope of the LMAP WG.

 

The basic i= nteraction between a Controller and MA is that the Controller sends an Inst= ruction to the MA, detailing what Measurement Tasks to do, when to do them,= and how to report the Measurement Results. In general we expect that the m= easurement system understands what Measurement Methods the MA can do and th= erefore the Controller can simply instruct the MA; there is no need for a n= egotiation protocol (which would add complexity to the MA, Controller and C= ontrol Protocol). However, it is possible that the MA is in fact not capabl= e of performing the requested Measurement Method, and so the Control Protoc= ol must allow the MA to reply with a suitable error code.

 

<bhs> The= use of the word “Instruction” here makes me uncomfortable, bec= ause it implies (at least to me) a manner of communication that is not quit= e consistent with the way most WAN-based massive-number-of-controlled-devic= es control protocols work today. “Instruction” suggests a manne= r of communication where the desired action is a part of the basic message.= Having separate message syntax (actions) for everything the Controller wan= ts the MA to do would greatly increase the number of messages that need to = go back and forth between MA and controller. This sort of interaction is co= mmon in protocols intended to work on LAN segments. It’s a very bad i= dea for protocols intended to work over the WAN that are intended to scale = to large numbers of devices, and be highly extensible. I would prefer if we= did not attempt to give this function of the Controller to MA interaction = a proper name (denoted by a capital first letter). I would also prefer if w= e described it as “the Controller configures the MA”, using the= word “configure” instead of “instruct”.

 <= /o:p>

I don= 217;t think we’ve defined “negotiation protocol”. Probabl= y because we don’t need it. I would prefer if we got rid of that (neg= otiation protocol) sentence and just used the last sentence as a positive s= tatement about what we do expect from the Control Protocol. For example: Th= e Control Protocol must support robust error reporting by the MA, to provid= e the Controller with sufficiently-detailed reasons for any failures in con= figuration.

 

Is “measurement system” defined? I’m a bit u= nclear on what this is.

 

Resulting recommended text:

<= p class=3DMsoNormal>The basic interaction between a Controller an= d MA is that the Controller configures the MA, detailing what Measurement T= asks to do, when to do them, and how to report the Measurement Results. In = general we expect that the Controller knows what Measurement Methods the MA= supports, such that the Controller can correctly configure the MA. However= , the Control Protocol must support robust error reporting by the MA, to pr= ovide the Controller with sufficiently-detailed reasons for any failures in= configuration.

 

The MA can send to the Controller the list of Meas= urement Methods that it is capable of. This could be useful:

[1] as part of the MA registering with the Controll= er. Note that in some scenarios it is not needed, as the Controller will kn= ow the information by other means, for example as part of the bootstrapping= process (using Tr-069 say) or because the MA is statically configured.

[2] so the MA can re-register, for examp= le if it becomes capable of a new Measurement Method.

** Comment: suggest we keep it simple and just send the c= omplete list, rather than a delta. The message should be short, since Metho= ds are referred to via a registry.

[3= ] when requested by the Controller, which could be useful if ‘somethi= ng goes wrong’ and the Controller forgets what the MA can do.

&nbs= p;

<b= hs> The word “register” also makes me uncomfortable, though = not as much as “Instruct”. This implies to me some very specifi= c functionality than I don’t consider completely necessary. But maybe= if “registration” were defined I would feel better about it. T= he “**Comment” suggestion is too specific for the Framework, IM= O. But if Framework has detailed Control Protocol criteria, then I would re= word the statement as “The Control Protocol must allow the Controller= to request the MA supply the MA’s complete list of supported Measure= ment Methods, in a concise format.”  I would prefer if the above= statements were reworded as:

The MA can send to the Controller the list of Measurement Methods th= at it is capable of. This could be useful:

[1] when the MA first communicates with a Controller. <= o:p>

[2] when the MA becomes= capable of a new Measurement Method.

[3] when requested by the Controller (e.g., if the Controll= er forgets what the MA can do or otherwise wants to resynchronize what it k= nows about the MA).

 

Note that the advert contains the list of Mea= surement Methods that the MA can perform. It is not intended to indicate dy= namic capabilities like the MA’s currently unused CPU, memory or batt= ery life.

** Comment: I’m not = sure whether we reached consensus on this point.

 

<bhs> I would have no objection to including such capabil= ities as optional elements of the information model. In fact, I think it wo= uld be a good idea. But I don’t think this needs to be mentioned in t= he Framework.

 

It is possible that later, when a MA is implementing = the Instruction, it does not perform a particular Measurement Task for some= reason, such as: the Measurement Peer is busy, or there is cross-traffic, = … The MA doesn’t inform the Controller, instead it is reported = to the Collector as part of the Measurement Report. The Collector may in tu= rn tell the measurement system or even the Controller, but this is out of s= cope of LMAP.

** Comment: are there a= ny conditions when it’s critical for the Controller to be informed?

 

= <bhs> Ditto my previous objection to “Instruction”. I bel= ieve the information model needs to include status parameters that would al= low the Controller to request this info, at some level. This can be optiona= l to support for MA and Controller. I recommend rewording to:

It is possible that an MA is unable = to carry out a configured Measurement Task. Possible reasons include the Me= asurement Peer being busy, presence of cross-traffic, … The MA will r= eport this information to the Collector as part of the Measurement Report. = The Collector may in turn tell other systems (including, possibly, the Cont= roller), but this is out of scope of LMAP. The MA may also be able to infor= m the Controller directly of such occurrences.

 

 

 

F= rom: lmap-bounces@= ietf.org [mailto:lmap-bounces@= ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: 05 September 2013 11:13
To:= lmap@ietf.org
Subject: = [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

 

Another issue:

There is= no negotiation between the MA and Controller - the Controller simply sends= the Instruction to the MA, with the details of the Measurement Tasks to pe= rform.

In general we expect that the= measurement system understands the capabilities of its MAs (probably there= are only one or a few classes of MA), so negotiation about the MA’s = capabilities would have little benefit. It would also add complexity to the= MA, Controller and Control Protocol.

It is possible that the MA c= an’t perform the requested Measurement Task. So the Control Protocol = needs to allow the MA to reply with an error code. It has also been suggest= ed that the Controller should be able to ask the MA to send a list of all t= he Measurement Methods that it is capable of, in case ‘something goes= wrong’ and the Controller forgets what the MA can do. Comment: this = idea hasn’t had much discussion yet, but appears in the Information M= odel i-d

 

=

Thoughts?

Thanks

phil

<= /div>
= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518905EMV67UKRDdoma_-- From bs7652@att.com Tue Sep 17 06:52:06 2013 Return-Path: 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 60ED511E826F for ; Tue, 17 Sep 2013 06:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] 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 shiX6ElzPSEZ for ; Tue, 17 Sep 2013 06:51:59 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id B6A7A11E8237 for ; Tue, 17 Sep 2013 06:51:55 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b7e58325.2aaad9421940.1837879.00-577.5052076.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 17 Sep 2013 13:51:55 +0000 (UTC) X-MXL-Hash: 52385e7b4d507211-77c92c4f555d0801a61c34036adb191b8eb3be7a Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 77e58325.0.1837851.00-447.5051976.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 17 Sep 2013 13:51:52 +0000 (UTC) X-MXL-Hash: 52385e78665da713-5cf765e569693bcc13c74adccd5ff7262465be6e Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8HDppl4004957; Tue, 17 Sep 2013 09:51:51 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8HDpe73004800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 09:51:49 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 17 Sep 2013 13:51:25 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0158.001; Tue, 17 Sep 2013 09:51:25 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsA== Date: Tue, 17 Sep 2013 13:51:24 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.183.97] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130370991GAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=WrCcx6jv c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=LMeTTcwMbu4A:10 a=l4EBnxoveaQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Lb5Mp4LI0] X-AnalysisOut: [xsA:10 a=e9qsufxtAAAA:8 a=48vgC7mUAAAA:8 a=egiC2ZBHEDWlMLI] X-AnalysisOut: [u7FMA:9 a=CjuIK1q_8ugA:10 a=W1qU_X6G3J8A:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=SExYAYpm8L-crhsf:21 a=JrHs4BLo9en4] X-AnalysisOut: [2Bz9:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:1] X-AnalysisOut: [0 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=] X-AnalysisOut: [nunoR-EEf0rPo2dd:21 a=6G4oqVjL3a39Vxur:21 a=qTgV0jrUAl5HRm] X-AnalysisOut: [wH:21] Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 13:52:06 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130370991GAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see that your use of "Instruction" is consistent with its proposed LMAP t= erminology definition. And I have no problem with there being a term with t= hat definition. It would appear that my problem is with the choice of "Instruction" as the = word to apply this definition to. The proposed terminology definition uses "Instruction" in a manner that I d= on't consider completely consistent with the way I generally use the word. In computing, "Instruction" is a very basic, low-level message. Such a mess= age tells the computer to do something very specific. There are many, many = instructions in a computer's "instruction set". I've also seen this term used with other inter-device communication. As wit= h computing "instructions", this sort of communication has many different t= ypes of messages, such that each desired action has its own "instruction". In the absence of actually reading the lmap terminology definition, and for= cing myself to accept that lmap is using this word in what I consider an in= dustry-inconsistent way, I would misinterpret the use of this word (and did= in fact misinterpret it). For me, "instruction" in the context of some of the xml-based WAN configura= tion protocols we're looking at, would map to an RPC (Remote Procedure Call= ), if there were not a terminology definition telling me that I should not = misinterpret the word in this manner. I believe it is problematic to select a term that is so commonly used in th= e industry, and provide it with a definition that is not consistent with th= at common usage. I believe the term could easily be replaced by: MA Configuration: The description of Measurement Tasks to perform and th= e details of the Report to send. The MA Configuration is sent by a Controller to a Measurement Agent. If we wanted to just call this Configuration, we could then add the sentenc= e: Also simply referred to as "Configuration" where the context is clear. Barbara From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Tuesday, September 17, 2013 5:59 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Thanks Barbara. thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. Not sure I fully understood your point about Instruction. I was trying to use it as defined in the terminology <> The Instruction would be a message with - one of more Measurement Tasks - one of more Schedules - one or more Report Channels I guess the first msg from Controller to MA includes all of these. Subseque= nt msgs might only update one of them, for instance the Schedule might get = updated rather more often than the other two items. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 12 September 2013 19:34 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_2D09D61DDFA73D4C884805CC7865E61130370991GAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see that your use of= “Instruction” is consistent with its proposed LMAP terminology= definition. And I have no problem with there being a term with that defini= tion.

 

It would appear that m= y problem is with the choice of “Instruction” as the word to ap= ply this definition to.

 

The proposed terminolo= gy definition uses “Instruction” in a manner that I don’t= consider completely consistent with the way I generally use the word.=

In computing, “I= nstruction” is a very basic, low-level message. Such a message tells = the computer to do something very specific. There are many, many instructio= ns in a computer’s “instruction set”.

I’ve also seen t= his term used with other inter-device communication. As with computing R= 20;instructions”, this sort of communication has many different types= of messages, such that each desired action has its own “instruction”.

In the absence of actu= ally reading = the lmap terminology definition, and forcing myself to accept that lmap is = using this word in what I consider an industry-inconsistent way, I would mi= sinterpret the use of this word (and did in fact misinterpret it).

For me, “instruc= tion” in the context of some of the xml-based WAN configuration proto= cols we’re looking at, would map to an RPC (Remote Procedure Call), i= f there were not a terminology definition telling me that I should not misinterpret the word in this manner.

I believe it is proble= matic to select a term that is so commonly used in the industry, and provid= e it with a definition that is not consistent with that common usage.<= /o:p>

 

I believe the term cou= ld easily be replaced by:

   MA Configuration: The description of Measurem= ent Tasks to perform and the

   details of the Report to send.  The MA C= onfiguration is sent by a

   Controller to a Measurement Agent.

 

If we wanted to just c= all this Configuration, we could then add the sentence:

Also simply referred to as “Configuration” whe= re the context is clear.

 

Barbara

 

 

From: philip.e= ardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Tuesday, September 17, 2013 5:59 AM
To: STARK, BARBARA H; lmap@ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

Thanks Barbara.=

thinking about = your process question – we’re now trying to write a ‘prot= ocol model’ for the framework doc (rfc4101) – so the protocol w= ill be described at this level.

 

Not sure I full= y understood your point about Instruction.

I was trying to= use it as defined in the terminology

<<=
Instruction: The description o=
f Measurement Tasks to perform and the

  = ; details of the Report to send.  The Instruction is sent by a

  = ; Controller to a Measurement Agent.

>> = ;

 <= /span>

The Instruction wo= uld be a message with

-one of mor= e Measurement Tasks

-one of mor= e Schedules

-one or mor= e Report Channels

I guess the first = msg from Controller to MA includes all of these. Subsequent msgs might only= update one of them, for instance the Schedule might get updated rather more often than the other two items.

 <= /span>

  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =    

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: 12 September 2013 19:34
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

First a process questi= on:

How detailed is this F= ramework document supposed to be? Is it intended to include the full list o= f criteria for a Control Protocol, or will these criteria be documented sep= arately? If the first, then I would prefer for the criteria to be more precisely described, and easy to identi= fy as Control Protocol criteria/requirements. If the latter, then I would p= refer for the Framework to use more descriptive language as to what is expe= cted of the Control Protocol, rather than trying to give names to all of the various expected functionality (e.= g., Instruction, registration). More detailed comments below.

Barbara

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Thursday, September 12, 2013 11:45 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions betwee= n MA and Controller

 

Thanks for the nice d= iscussion, I’ve tried to re-write to reflect where I think we’v= e got to. I also changed the title to:

 

Interactions between = MA and Controller

As part of a bootstra= p process the MA gets sufficient information to contact a Controller. Defin= ing a bootstrap mechanism is out of scope of the LMAP WG.=

 

The basic interaction= between a Controller and MA is that the Controller sends an Instruction to= the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect that= the measurement system understands what Measurement Methods the MA can do = and therefore the Controller can simply instruct the MA; there is no need f= or a negotiation protocol (which would add complexity to the MA, Controller and Control Protocol). However,= it is possible that the MA is in fact not capable of performing the reques= ted Measurement Method, and so the Control Protocol must allow the MA to re= ply with a suitable error code.

&n= bsp;

<bhs= > The use of the word “Instruction” here makes me uncomforta= ble, because it implies (at least to me) a manner of communication that is = not quite consistent with the way most WAN-based massive-number-of-controll= ed-devices control protocols work today. “Instruction” suggests a manner = of communication where the desired action is a part of the basic message. H= aving separate message syntax (actions) for everything the Controller wants= the MA to do would greatly increase the number of messages that need to go back and forth between MA and controller. This= sort of interaction is common in protocols intended to work on LAN segment= s. It’s a very bad idea for protocols intended to work over the WAN t= hat are intended to scale to large numbers of devices, and be highly extensible. I would prefer if we did not attempt= to give this function of the Controller to MA interaction a proper name (d= enoted by a capital first letter). I would also prefer if we described it a= s “the Controller configures the MA”, using the word “configure” instead of “instru= ct”.

&n= bsp;

I don&#= 8217;t think we’ve defined “negotiation protocol”. Probab= ly because we don’t need it. I would prefer if we got rid of that (ne= gotiation protocol) sentence and just used the last sentence as a positive statement about what we do expect from the Control Protocol. For example: = The Control Protocol must support robust error reporting by the MA, to prov= ide the Controller with sufficiently-detailed reasons for any failures in c= onfiguration.

&n= bsp;

Is R= 20;measurement system” defined? I’m a bit unclear on what this = is.

&n= bsp;

Resulti= ng recommended text:

The bas= ic interaction between a Controller and MA is that the Controller configure= s the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect t= hat the Controller knows what Measurement Methods the MA supports, such tha= t the Controller can correctly configure the MA. However, the Control Proto= col must support robust error reporting by the MA, to provide the Controller with sufficiently-detailed reasons fo= r any failures in configuration.

 

The MA can send to th= e Controller the list of Measurement Methods that it is capable of. This co= uld be useful:

[1] as part of the MA= registering with the Controller. Note that in some scenarios it is not nee= ded, as the Controller will know the information by other means, for example as part of the bootstrapping process (using Tr-069 say)= or because the MA is statically configured.

[2] so the MA can re-= register, for example if it becomes capable of a new Measurement Method.

** Comment: suggest w= e keep it simple and just send the complete list, rather than a delta. The = message should be short, since Methods are referred to via a registry.

[3] when requested by= the Controller, which could be useful if ‘something goes wrong’= ; and the Controller forgets what the MA can do.

&n= bsp;

<bhs= > The word “register” also makes me uncomfortable, though no= t as much as “Instruct”. This implies to me some very specific = functionality than I don’t consider completely necessary. But maybe if “registration” were defined I would feel better about it. T= he “**Comment” suggestion is too specific for the Framework, IM= O. But if Framework has detailed Control Protocol criteria, then I would re= word the statement as “The Control Protocol must allow the Controller to request the MA supply the MA’s complete list of suppor= ted Measurement Methods, in a concise format.”  I would prefer i= f the above statements were reworded as:

The MA = can send to the Controller the list of Measurement Methods that it is capab= le of. This could be useful:

[1] whe= n the MA first communicates with a Controller.

[2] whe= n the MA becomes capable of a new Measurement Method.

[3] whe= n requested by the Controller (e.g., if the Controller forgets what the MA = can do or otherwise wants to resynchronize what it knows about the MA).

 

Note that the advert = contains the list of Measurement Methods that the MA can perform. It is not= intended to indicate dynamic capabilities like the MA’s currently unused CPU, memory or battery life.

** Comment: I’m= not sure whether we reached consensus on this point.

&n= bsp;

<bhs= > I would have no objection to including such capabilities as optional e= lements of the information model. In fact, I think it would be a good idea.= But I don’t think this needs to be mentioned in the Framework.

 

It is possible that l= ater, when a MA is implementing the Instruction, it does not perform a part= icular Measurement Task for some reason, such as: the Measurement Peer is busy, or there is cross-traffic, … The MA doesn’t info= rm the Controller, instead it is reported to the Collector as part of the M= easurement Report. The Collector may in turn tell the measurement system or= even the Controller, but this is out of scope of LMAP.

** Comment: are there= any conditions when it’s critical for the Controller to be informed?=

&n= bsp;

<bhs= > Ditto my previous objection to “Instruction”. I believe th= e information model needs to include status parameters that would allow the= Controller to request this info, at some level. This can be optional to support for MA and Controller. I recommend rewording to:

It is p= ossible that an MA is unable to carry out a configured Measurement Task. Po= ssible reasons include the Measurement Peer being busy, presence of cross-traffic, … The MA will report this information to the Colle= ctor as part of the Measurement Report. The Collector may in turn tell othe= r systems (including, possibly, the Controller), but this is out of scope o= f LMAP. The MA may also be able to inform the Controller directly of such occurrences.

&n= bsp;

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 05 September 2013 11:13
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 No negotiation between MA an= d Controller

 

Another issue:

There is no negotiati= on between the MA and Controller - the Controller simply sends the Instruct= ion to the MA, with the details of the Measurement Tasks to perform.

In general we expect = that the measurement system understands the capabilities of its MAs (probab= ly there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. It would also= add complexity to the MA, Controller and Control Protocol.

 

It is possible that t= he MA can’t perform the requested Measurement Task. So the Control Pr= otocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to se= nd a list of all the Measurement Methods that it is capable of, in case = 216;something goes wrong’ and the Controller forgets what the MA can = do. Comment: this idea hasn’t had much discussion yet, but appears in the Information Model i-d

 

Thoughts?

Thanks

phil

--_000_2D09D61DDFA73D4C884805CC7865E61130370991GAALPA1MSGUSR9L_-- From Michael.K.Bugenhagen@centurylink.com Tue Sep 17 07:01:07 2013 Return-Path: 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 8881111E8263 for ; Tue, 17 Sep 2013 07:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] 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 9rMqwGFPmw0l for ; Tue, 17 Sep 2013 07:00:59 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 25D2B11E8237 for ; Tue, 17 Sep 2013 07:00:58 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r8HE0qtA015095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 09:00:52 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 468E21E0067; Tue, 17 Sep 2013 09:00:47 -0500 (CDT) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 0A4931E003F; Tue, 17 Sep 2013 09:00:47 -0500 (CDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r8HE0kmu014039; Tue, 17 Sep 2013 08:00:46 -0600 (MDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r8HE0iMf013977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Sep 2013 08:00:46 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.02.0318.001; Tue, 17 Sep 2013 09:00:45 -0500 From: "Bugenhagen, Michael K" To: "'STARK, BARBARA H'" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAABCDBQ Date: Tue, 17 Sep 2013 14:00:45 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C1516podcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 14:01:07 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C1516podcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adding a bit to some of Barbara's input What should be passed to a MA 1) Schedule to initiate testing 2) Policy of what testing to accept (who, what type, ....) The big question I have is when does a MA check it's test schedule to see i= f can actually handle it. I would expect that a) The MA do a cursory test capability check on it's test schedule to = make sure it can do a test - IF NOT it should reject it (not a negotiation = but a "accept / reject") Again this is to fix the "I thought everything was running ok" issue. When Op's sets up a test to run overnight only to fin= d out the bulk of the test points couldn't run it .... May be the last tim= e they use that system. b) The MA does a resource check to approve or deny a test once the tim= e to test (schedule) is reached - I'm saying it should do test call admissi= on pre-test-flight checks and then permit or deny the Test initiation. From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STA= RK, BARBARA H Sent: Tuesday, September 17, 2013 8:51 AM To: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller I see that your use of "Instruction" is consistent with its proposed LMAP t= erminology definition. And I have no problem with there being a term with t= hat definition. It would appear that my problem is with the choice of "Instruction" as the = word to apply this definition to. The proposed terminology definition uses "Instruction" in a manner that I d= on't consider completely consistent with the way I generally use the word. In computing, "Instruction" is a very basic, low-level message. Such a mess= age tells the computer to do something very specific. There are many, many = instructions in a computer's "instruction set". I've also seen this term used with other inter-device communication. As wit= h computing "instructions", this sort of communication has many different t= ypes of messages, such that each desired action has its own "instruction". In the absence of actually reading the lmap terminology definition, and for= cing myself to accept that lmap is using this word in what I consider an in= dustry-inconsistent way, I would misinterpret the use of this word (and did= in fact misinterpret it). For me, "instruction" in the context of some of the xml-based WAN configura= tion protocols we're looking at, would map to an RPC (Remote Procedure Call= ), if there were not a terminology definition telling me that I should not = misinterpret the word in this manner. I believe it is problematic to select a term that is so commonly used in th= e industry, and provide it with a definition that is not consistent with th= at common usage. I believe the term could easily be replaced by: MA Configuration: The description of Measurement Tasks to perform and th= e details of the Report to send. The MA Configuration is sent by a Controller to a Measurement Agent. If we wanted to just call this Configuration, we could then add the sentenc= e: Also simply referred to as "Configuration" where the context is clear. Barbara From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Tuesday, September 17, 2013 5:59 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Thanks Barbara. thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. Not sure I fully understood your point about Instruction. I was trying to use it as defined in the terminology <> The Instruction would be a message with - one of more Measurement Tasks - one of more Schedules - one or more Report Channels I guess the first msg from Controller to MA includes all of these. Subseque= nt msgs might only update one of them, for instance the Schedule might get = updated rather more often than the other two items. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 12 September 2013 19:34 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C1516podcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adding a bit to some o= f Barbara’s input

 

What should be passed = to a MA

1)&n= bsp;     Schedule to in= itiate testing

2)&n= bsp;     Policy of what= testing to accept (who, what type, ….)

 

The big question I hav= e is when does a MA check it’s test schedule to see if can actually h= andle it.

I would expect that

a) &nbs= p;    The MA do a cu= rsory test capability check on it’s test schedule to make sure it can= do a test – IF NOT it should reject it (not a negotiation but a R= 20;accept / reject”)

      Again this is to fix the ̶= 0;I thought everything was running ok” issue.

          &= nbsp;           When Op&#= 8217;s sets up a test to run overnight only to find out the bulk of the tes= t points couldn’t run it ….  May be the last time they use= that system.

 

b) &nbs= p;    The MA does a = resource check to approve or deny a test once the time to test (schedule) i= s reached – I’m saying it should do test call admission pre-tes= t-flight checks and then permit or deny the

      Test initiation.

 

 

 

 

 

 

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H
Sent: Tuesday, September 17, 2013 8:51 AM
To: philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

I see that your use of= “Instruction” is consistent with its proposed LMAP terminology= definition. And I have no problem with there being a term with that defini= tion.

 

It would appear that m= y problem is with the choice of “Instruction” as the word to ap= ply this definition to.

 

The proposed terminolo= gy definition uses “Instruction” in a manner that I don’t= consider completely consistent with the way I generally use the word.=

In computing, “I= nstruction” is a very basic, low-level message. Such a message tells = the computer to do something very specific. There are many, many instructio= ns in a computer’s “instruction set”.

I’ve also seen t= his term used with other inter-device communication. As with computing R= 20;instructions”, this sort of communication has many different types= of messages, such that each desired action has its own “instruction”.

In the absence of actu= ally reading the lmap terminology definition, and forcing myself to accept = that lmap is using this word in what I consider an industry-inconsistent wa= y, I would misinterpret the use of this word (and did in fact misinterpret it).

For me, “instruc= tion” in the context of some of the xml-based WAN configuration proto= cols we’re looking at, would map to an RPC (Remote Procedure Call), i= f there were not a terminology definition telling me that I should not misinterpret the word in this manner.

I believe it is proble= matic to select a term that is so commonly used in the industry, and provid= e it with a definition that is not consistent with that common usage.<= /o:p>

 

I believe the term cou= ld easily be replaced by:

   MA Configuration: The description of Measurem= ent Tasks to perform and the

   details of the Report to send.  The MA C= onfiguration is sent by a

   Controller to a Measurement Agent.

 

If we wanted to just c= all this Configuration, we could then add the sentence:

Also simply referred to as “Configuration” whe= re the context is clear.

 

Barbara

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Tuesday, September 17, 2013 5:59 AM
To: STARK, BARBARA H; lmap@ietf.org=
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

Thanks Barbara.=

thinking about = your process question – we’re now trying to write a ‘prot= ocol model’ for the framework doc (rfc4101) – so the protocol w= ill be described at this level.

 

Not sure I full= y understood your point about Instruction.

I was trying to= use it as defined in the terminology

<<=
Instruction: The description o=
f Measurement Tasks to perform and the

  = ; details of the Report to send.  The Instruction is sent by a

  = ; Controller to a Measurement Agent.

>> = ;

 <= /span>

The Instruction wo= uld be a message with

-one of mor= e Measurement Tasks

-one of mor= e Schedules

-one or mor= e Report Channels

I guess the first = msg from Controller to MA includes all of these. Subsequent msgs might only= update one of them, for instance the Schedule might get updated rather more often than the other two items.

 <= /span>

  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =    

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: 12 September 2013 19:34
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

First a process questi= on:

How detailed is this F= ramework document supposed to be? Is it intended to include the full list o= f criteria for a Control Protocol, or will these criteria be documented sep= arately? If the first, then I would prefer for the criteria to be more precisely described, and easy to identi= fy as Control Protocol criteria/requirements. If the latter, then I would p= refer for the Framework to use more descriptive language as to what is expe= cted of the Control Protocol, rather than trying to give names to all of the various expected functionality (e.= g., Instruction, registration). More detailed comments below.

Barbara

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Thursday, September 12, 2013 11:45 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions betwee= n MA and Controller

 

Thanks for the nice d= iscussion, I’ve tried to re-write to reflect where I think we’v= e got to. I also changed the title to:

 

Interactions between = MA and Controller

As part of a bootstra= p process the MA gets sufficient information to contact a Controller. Defin= ing a bootstrap mechanism is out of scope of the LMAP WG.=

 

The basic interaction= between a Controller and MA is that the Controller sends an Instruction to= the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect that= the measurement system understands what Measurement Methods the MA can do = and therefore the Controller can simply instruct the MA; there is no need f= or a negotiation protocol (which would add complexity to the MA, Controller and Control Protocol). However,= it is possible that the MA is in fact not capable of performing the reques= ted Measurement Method, and so the Control Protocol must allow the MA to re= ply with a suitable error code.

&n= bsp;

<bhs= > The use of the word “Instruction” here makes me uncomforta= ble, because it implies (at least to me) a manner of communication that is = not quite consistent with the way most WAN-based massive-number-of-controll= ed-devices control protocols work today. “Instruction” suggests a manner = of communication where the desired action is a part of the basic message. H= aving separate message syntax (actions) for everything the Controller wants= the MA to do would greatly increase the number of messages that need to go back and forth between MA and controller. This= sort of interaction is common in protocols intended to work on LAN segment= s. It’s a very bad idea for protocols intended to work over the WAN t= hat are intended to scale to large numbers of devices, and be highly extensible. I would prefer if we did not attempt= to give this function of the Controller to MA interaction a proper name (d= enoted by a capital first letter). I would also prefer if we described it a= s “the Controller configures the MA”, using the word “configure” instead of “instru= ct”.

&n= bsp;

I don&#= 8217;t think we’ve defined “negotiation protocol”. Probab= ly because we don’t need it. I would prefer if we got rid of that (ne= gotiation protocol) sentence and just used the last sentence as a positive statement about what we do expect from the Control Protocol. For example: = The Control Protocol must support robust error reporting by the MA, to prov= ide the Controller with sufficiently-detailed reasons for any failures in c= onfiguration.

&n= bsp;

Is R= 20;measurement system” defined? I’m a bit unclear on what this = is.

&n= bsp;

Resulti= ng recommended text:

The bas= ic interaction between a Controller and MA is that the Controller configure= s the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect t= hat the Controller knows what Measurement Methods the MA supports, such tha= t the Controller can correctly configure the MA. However, the Control Proto= col must support robust error reporting by the MA, to provide the Controller with sufficiently-detailed reasons fo= r any failures in configuration.

 

The MA can send to th= e Controller the list of Measurement Methods that it is capable of. This co= uld be useful:

[1] as part of the MA= registering with the Controller. Note that in some scenarios it is not nee= ded, as the Controller will know the information by other means, for example as part of the bootstrapping process (using Tr-069 say)= or because the MA is statically configured.

[2] so the MA can re-= register, for example if it becomes capable of a new Measurement Method.

** Comment: suggest w= e keep it simple and just send the complete list, rather than a delta. The = message should be short, since Methods are referred to via a registry.

[3] when requested by= the Controller, which could be useful if ‘something goes wrong’= ; and the Controller forgets what the MA can do.

&n= bsp;

<bhs= > The word “register” also makes me uncomfortable, though no= t as much as “Instruct”. This implies to me some very specific = functionality than I don’t consider completely necessary. But maybe if “registration” were defined I would feel better about it. T= he “**Comment” suggestion is too specific for the Framework, IM= O. But if Framework has detailed Control Protocol criteria, then I would re= word the statement as “The Control Protocol must allow the Controller to request the MA supply the MA’s complete list of suppor= ted Measurement Methods, in a concise format.”  I would prefer i= f the above statements were reworded as:

The MA = can send to the Controller the list of Measurement Methods that it is capab= le of. This could be useful:

[1] whe= n the MA first communicates with a Controller.

[2] whe= n the MA becomes capable of a new Measurement Method.

[3] whe= n requested by the Controller (e.g., if the Controller forgets what the MA = can do or otherwise wants to resynchronize what it knows about the MA).

 

Note that the advert = contains the list of Measurement Methods that the MA can perform. It is not= intended to indicate dynamic capabilities like the MA’s currently unused CPU, memory or battery life.

** Comment: I’m= not sure whether we reached consensus on this point.

&n= bsp;

<bhs= > I would have no objection to including such capabilities as optional e= lements of the information model. In fact, I think it would be a good idea.= But I don’t think this needs to be mentioned in the Framework.

 

It is possible that l= ater, when a MA is implementing the Instruction, it does not perform a part= icular Measurement Task for some reason, such as: the Measurement Peer is busy, or there is cross-traffic, … The MA doesn’t info= rm the Controller, instead it is reported to the Collector as part of the M= easurement Report. The Collector may in turn tell the measurement system or= even the Controller, but this is out of scope of LMAP.

** Comment: are there= any conditions when it’s critical for the Controller to be informed?=

&n= bsp;

<bhs= > Ditto my previous objection to “Instruction”. I believe th= e information model needs to include status parameters that would allow the= Controller to request this info, at some level. This can be optional to support for MA and Controller. I recommend rewording to:

It is p= ossible that an MA is unable to carry out a configured Measurement Task. Po= ssible reasons include the Measurement Peer being busy, presence of cross-traffic, … The MA will report this information to the Colle= ctor as part of the Measurement Report. The Collector may in turn tell othe= r systems (including, possibly, the Controller), but this is out of scope o= f LMAP. The MA may also be able to inform the Controller directly of such occurrences.

&n= bsp;

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 05 September 2013 11:13
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 No negotiation between MA an= d Controller

 

Another issue:

There is no negotiati= on between the MA and Controller - the Controller simply sends the Instruct= ion to the MA, with the details of the Measurement Tasks to perform.

In general we expect = that the measurement system understands the capabilities of its MAs (probab= ly there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. It would also= add complexity to the MA, Controller and Control Protocol.

 

It is possible that t= he MA can’t perform the requested Measurement Task. So the Control Pr= otocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to se= nd a list of all the Measurement Methods that it is capable of, in case = 216;something goes wrong’ and the Controller forgets what the MA can = do. Comment: this idea hasn’t had much discussion yet, but appears in the Information Model i-d

 

Thoughts?

Thanks

phil

--_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C1516podcwmbxex505ct_-- From philip.eardley@bt.com Tue Sep 17 08:15:47 2013 Return-Path: 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 ACBC311E8473 for ; Tue, 17 Sep 2013 08:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.236 X-Spam-Level: X-Spam-Status: No, score=-104.236 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 g+t0JspwIrGO for ; Tue, 17 Sep 2013 08:15:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 34F6D11E8289 for ; Tue, 17 Sep 2013 08:15:37 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 17 Sep 2013 16:15:36 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 17 Sep 2013 16:15:36 +0100 From: To: , Date: Tue, 17 Sep 2013 16:15:34 +0100 Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAAD0Ahw Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518A20EMV67UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:15:47 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518A20EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What do other people think? I don't have a strong feeling either way. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 September 2013 14:51 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller I see that your use of "Instruction" is consistent with its proposed LMAP t= erminology definition. And I have no problem with there being a term with t= hat definition. It would appear that my problem is with the choice of "Instruction" as the = word to apply this definition to. The proposed terminology definition uses "Instruction" in a manner that I d= on't consider completely consistent with the way I generally use the word. In computing, "Instruction" is a very basic, low-level message. Such a mess= age tells the computer to do something very specific. There are many, many = instructions in a computer's "instruction set". I've also seen this term used with other inter-device communication. As wit= h computing "instructions", this sort of communication has many different t= ypes of messages, such that each desired action has its own "instruction". In the absence of actually reading the lmap terminology definition, and for= cing myself to accept that lmap is using this word in what I consider an in= dustry-inconsistent way, I would misinterpret the use of this word (and did= in fact misinterpret it). For me, "instruction" in the context of some of the xml-based WAN configura= tion protocols we're looking at, would map to an RPC (Remote Procedure Call= ), if there were not a terminology definition telling me that I should not = misinterpret the word in this manner. I believe it is problematic to select a term that is so commonly used in th= e industry, and provide it with a definition that is not consistent with th= at common usage. I believe the term could easily be replaced by: MA Configuration: The description of Measurement Tasks to perform and th= e details of the Report to send. The MA Configuration is sent by a Controller to a Measurement Agent. If we wanted to just call this Configuration, we could then add the sentenc= e: Also simply referred to as "Configuration" where the context is clear. Barbara From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Tuesday, September 17, 2013 5:59 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Thanks Barbara. thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. Not sure I fully understood your point about Instruction. I was trying to use it as defined in the terminology <> The Instruction would be a message with - one of more Measurement Tasks - one of more Schedules - one or more Report Channels I guess the first msg from Controller to MA includes all of these. Subseque= nt msgs might only update one of them, for instance the Schedule might get = updated rather more often than the other two items. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 12 September 2013 19:34 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518A20EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What do other = people think?

I don’t hav= e a strong feeling either way.

<= span style=3D'font-size:12.0pt;font-family:"Arial","sans-serif";color:blue'= > 

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'>From: STARK, BARBARA H [mailto:bs7652@att.com]
S= ent: 17 September 2013 14:51
To: Eardley,PL,Philip,TUB8 R; lm= ap@ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) = Interactions between MA and Controller

 

I see that your use of “Instruction”= ; is consistent with its proposed LMAP terminology definition. And I have n= o problem with there being a term with that definition. <= /p>

&nb= sp;

It would appear that my problem is with the choice of “Instr= uction” as the word to apply this definition to.

 = ;

The proposed terminology definition uses “Instruction” i= n a manner that I don’t consider completely consistent with the way I= generally use the word.

In computing, “Instruction” = is a very basic, low-level message. Such a message tells the computer to do= something very specific. There are many, many instructions in a computer&#= 8217;s “instruction set”.

I’ve also seen this t= erm used with other inter-device communication. As with computing “in= structions”, this sort of communication has many different types of m= essages, such that each desired action has its own “instruction”= ;.

In the absence of actually reading the lmap terminology defini= tion, and forcing myself to accept that lmap is using this word in what I c= onsider an industry-inconsistent way, I would misinterpret the use of this = word (and did in fact misinterpret it).

For me, “instructio= n” in the context of some of the xml-based WAN configuration protocol= s we’re looking at, would map to an RPC (Remote Procedure Call), if t= here were not a terminology definition telling me that I should not misinte= rpret the word in this manner.

<= span lang=3DEN-US style=3D'color:#1F497D'>I believe it is problematic to se= lect a term that is so commonly used in the industry, and provide it with a= definition that is not consistent with that common usage.

&= nbsp;

I believe the term could easily be replaced by:

   MA Configuration: The description of Me= asurement Tasks to perform and the

&= nbsp;  details of the Report to send.  The MA Configuration is se= nt by a

   Controller to = a Measurement Agent.

 

If we wanted to just call this Configuration, we could then add the sen= tence:

Also simply referred to as = “Configuration” where the context is clear.

&nbs= p;

Barbara

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent= : Tuesday, September 17, 2013 5:59 AM
To: STARK, BARBARA H; <= a href=3D"mailto:lmap@ietf.org">lmap@ietf.org
Subject: RE: [l= map] LMAP Framework issue #3 (take 2) Interactions between MA and Controlle= r

=  

Thanks Barbara.

thinking about your process question &#= 8211; we’re now trying to write a ‘protocol model’ for th= e framework doc (rfc4101) – so the protocol will be described at this= level.

 

Not sure I fully understood your point about I= nstruction.

I was trying to use= it as defined in the terminology

<<Instruction:=
 The description of Measurement Tasks to perform and the<=
/pre>
   details=
 of the Report to send.  The Instruction is sent by a
   Control=
ler to a Measurement Agent.
>> 
 
The Instruct=
ion would be a message with 
-       one of more Measurement Tasks
<=
p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'>-     &nb=
sp; one of more Schedules
-   =
;    one or more =
Report Channels
I gue=
ss the first msg from Controller to MA includes all of these. Subsequent ms=
gs might only update one of them, for instance the Schedule might get updat=
ed rather more often than the other two items. 
 
            =
            &nb=
sp;            =
            &nb=
sp;            =
       
From: STARK, BARBARA H [=
mailto:bs7652@att.com] 
Sent: 12 September 2013 19:34
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: [lmap] L=
MAP Framework issue #3 (take 2) Interactions between MA and Controller=

 
First a process=
 question:
How detailed is this Framework document supposed to be=
? Is it intended to include the full list of criteria for a Control Protoco=
l, or will these criteria be documented separately? If the first, then I wo=
uld prefer for the criteria to be more precisely described, and easy to ide=
ntify as Control Protocol criteria/requirements. If the latter, then I woul=
d prefer for the Framework to use more descriptive language as to what is e=
xpected of the Control Protocol, rather than trying to give names to all of=
 the various expected functionality (e.g., Instruction, registration). More=
 detailed comments below.
Barbara
 
From:=
 lmap-bounces@ietf.org [<=
a href=3D"mailto:lmap-bounces@ietf.org">mailto:lmap-bounces@ietf.org] <=
b>On Behalf Of philip.eardley@=
bt.com
Sent: Thursday, September 12, 2013 11:45 AM
To:<=
/b> lmap@ietf.org
Subject: [=
lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controll=
er
 
Thanks for the nice discussio=
n, I’ve tried to re-write to reflect where I think we’ve got to=
. I also changed the title to:
&=
nbsp;
Interactions between MA and Controll=
er
As part of a bootstrap process the=
 MA gets sufficient information to contact a Controller. Defining a bootstr=
ap mechanism is out of scope of the LMAP WG.
 
The basic interaction=
 between a Controller and MA is that the Controller sends an Instruction to=
 the MA, detailing what Measurement Tasks to do, when to do them, and how t=
o report the Measurement Results. In general we expect that the measurement=
 system understands what Measurement Methods the MA can do and therefore th=
e Controller can simply instruct the MA; there is no need for a negotiation=
 protocol (which would add complexity to the MA, Controller and Control Pro=
tocol). However, it is possible that the MA is in fact not capable of perfo=
rming the requested Measurement Method, and so the Control Protocol must al=
low the MA to reply with a suitable error code. 
 
<=
p class=3DMsoNormal><bhs> The use of th=
e word “Instruction” here makes me uncomfortable, because it im=
plies (at least to me) a manner of communication that is not quite consiste=
nt with the way most WAN-based massive-number-of-controlled-devices control=
 protocols work today. “Instruction” suggests a manner of commu=
nication where the desired action is a part of the basic message. Having se=
parate message syntax (actions) for everything the Controller wants the MA =
to do would greatly increase the number of messages that need to go back an=
d forth between MA and controller. This sort of interaction is common in pr=
otocols intended to work on LAN segments. It’s a very bad idea for pr=
otocols intended to work over the WAN that are intended to scale to large n=
umbers of devices, and be highly extensible. I would prefer if we did not a=
ttempt to give this function of the Controller to MA interaction a proper n=
ame (denoted by a capital first letter). I would also prefer if we describe=
d it as “the Controller configures the MA”, using the word R=
20;configure” instead of “instruct”. 
 
I don’t thin=
k we’ve defined “negotiation protocol”. Probably because =
we don’t need it. I would prefer if we got rid of that (negotiation p=
rotocol) sentence and just used the last sentence as a positive statement a=
bout what we do expect from the Control Protocol. For example: The Control =
Protocol must support robust error reporting by the MA, to provide the Cont=
roller with sufficiently-detailed reasons for any failures in configuration=
.
<=
o:p> 
Is “measurement system” defined? I’m a bit unclear on =
what this is.
 
Resulting recommended text:
The basic interaction between a Controller and MA is th=
at the Controller configures the MA, detailing what Measurement Tasks to do=
, when to do them, and how to report the Measurement Results. In general we=
 expect that the Controller knows what Measurement Methods the MA supports,=
 such that the Controller can correctly configure the MA. However, the Cont=
rol Protocol must support robust error reporting by the MA, to provide the =
Controller with sufficiently-detailed reasons for any failures in configura=
tion. 
 
The MA can send to the Controller the list of Measurement Me=
thods that it is capable of. This could be useful:
[1] as part of the MA registering with the Controller. Note t=
hat in some scenarios it is not needed, as the Controller will know the inf=
ormation by other means, for example as part of the bootstrapping process (=
using Tr-069 say) or because the MA is statically configured.
[2] so the MA can re-register, for example if it b=
ecomes capable of a new Measurement Method. 
** Comment: suggest we keep it simple and just send the complete l=
ist, rather than a delta. The message should be short, since Methods are re=
ferred to via a registry.
[3] when re=
quested by the Controller, which could be useful if ‘something goes w=
rong’ and the Controller forgets what the MA can do. 
 <=
/span>
<bhs> Th=
e word “register” also makes me uncomfortable, though not as mu=
ch as “Instruct”. This implies to me some very specific functio=
nality than I don’t consider completely necessary. But maybe if ̶=
0;registration” were defined I would feel better about it. The “=
;**Comment” suggestion is too specific for the Framework, IMO. But if=
 Framework has detailed Control Protocol criteria, then I would reword the =
statement as “The Control Protocol must allow the Controller to reque=
st the MA supply the MA’s complete list of supported Measurement Meth=
ods, in a concise format.”  I would prefer if the above statemen=
ts were reworded as:
T=
he MA can send to the Controller the list of Measurement Methods that it is=
 capable of. This could be useful:
[1] when the MA first communicates with a Controller. 
[2] when the MA becomes capable=
 of a new Measurement Method. 
[3] when requested by the Controller (e.g., if the Controller forge=
ts what the MA can do or otherwise wants to resynchronize what it knows abo=
ut the MA).
 <=
/p>
Note that the advert contains the list of Measurement M=
ethods that the MA can perform. It is not intended to indicate dynamic capa=
bilities like the MA’s currently unused CPU, memory or battery life. =

** Comment: I’m not sure wheth=
er we reached consensus on this point.
 
<bhs> I would have no objection to including such capabilities as o=
ptional elements of the information model. In fact, I think it would be a g=
ood idea. But I don’t think this needs to be mentioned in the Framewo=
rk.
 
It is possible that later, when a MA is implementing the Instru=
ction, it does not perform a particular Measurement Task for some reason, s=
uch as: the Measurement Peer is busy, or there is cross-traffic, … Th=
e MA doesn’t inform the Controller, instead it is reported to the Col=
lector as part of the Measurement Report. The Collector may in turn tell th=
e measurement system or even the Controller, but this is out of scope of LM=
AP.
** Comment: are there any conditi=
ons when it’s critical for the Controller to be informed?<=
/span>
 
<bhs>=
; Ditto my previous objection to “Instruction”. I believe the i=
nformation model needs to include status parameters that would allow the Co=
ntroller to request this info, at some level. This can be optional to suppo=
rt for MA and Controller. I recommend rewording to:
It is possible that an MA is unable to carry o=
ut a configured Measurement Task. Possible reasons include the Measurement =
Peer being busy, presence of cross-traffic, … The MA will report this=
 information to the Collector as part of the Measurement Report. The Collec=
tor may in turn tell other systems (including, possibly, the Controller), b=
ut this is out of scope of LMAP. The MA may also be able to inform the Cont=
roller directly of such occurrences.
 
 
 
From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.ear=
dley@bt.com
Sent: 05 September 2013 11:13
To: lmap@ietf.org
Subject: [lmap] LMA=
P Framework issue #3 No negotiation between MA and Controller
 
Another issue:
There is no negoti=
ation between the MA and Controller - the Controller simply sends the Instr=
uction to the MA, with the details of the Measurement Tasks to perform. 
In general we expect that the measureme=
nt system understands the capabilities of its MAs (probably there are only =
one or a few classes of MA), so negotiation about the MA’s capabiliti=
es would have little benefit. It would also add complexity to the MA, Contr=
oller and Control Protocol. 
&nb=
sp;
It is possible that the MA can’t=
 perform the requested Measurement Task. So the Control Protocol needs to a=
llow the MA to reply with an error code. It has also been suggested that th=
e Controller should be able to ask the MA to send a list of all the Measure=
ment Methods that it is capable of, in case ‘something goes wrongR=
17; and the Controller forgets what the MA can do. Comment: this idea hasn&=
#8217;t had much discussion yet, but appears in the Information Model i-d
 
Thoughts? 
Thanks
phil
<= /div>
= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518A20EMV67UKRDdoma_-- From timothy.carey@alcatel-lucent.com Tue Sep 17 08:22:22 2013 Return-Path: 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 394E411E8283 for ; Tue, 17 Sep 2013 08:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.998 X-Spam-Level: X-Spam-Status: No, score=-11.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, 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 sOGAxJuDXbDD for ; Tue, 17 Sep 2013 08:22:14 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5F33121F9C90 for ; Tue, 17 Sep 2013 08:21:51 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r8HFLcBi009357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Sep 2013 10:21:39 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r8HFLbGJ010284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Sep 2013 11:21:38 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Tue, 17 Sep 2013 11:21:37 -0400 From: "Carey, Timothy (Timothy)" To: "philip.eardley@bt.com" , "bs7652@att.com" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: AQHOs7jPzYlPP5McVUyhtBy5o1EOWpnKC4Bg Date: Tue, 17 Sep 2013 15:21:36 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771E33B3@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771E33B3US70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:22:22 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771E33B3US70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil If the definition of Instruction was limited to MA Configuration (which in = the current definition it seems to be) then Barbara's definition is more cl= ear. BR, Tim From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Tuesday, September 17, 2013 11:16 AM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller What do other people think? I don't have a strong feeling either way. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 September 2013 14:51 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller I see that your use of "Instruction" is consistent with its proposed LMAP t= erminology definition. And I have no problem with there being a term with t= hat definition. It would appear that my problem is with the choice of "Instruction" as the = word to apply this definition to. The proposed terminology definition uses "Instruction" in a manner that I d= on't consider completely consistent with the way I generally use the word. In computing, "Instruction" is a very basic, low-level message. Such a mess= age tells the computer to do something very specific. There are many, many = instructions in a computer's "instruction set". I've also seen this term used with other inter-device communication. As wit= h computing "instructions", this sort of communication has many different t= ypes of messages, such that each desired action has its own "instruction". In the absence of actually reading the lmap terminology definition, and for= cing myself to accept that lmap is using this word in what I consider an in= dustry-inconsistent way, I would misinterpret the use of this word (and did= in fact misinterpret it). For me, "instruction" in the context of some of the xml-based WAN configura= tion protocols we're looking at, would map to an RPC (Remote Procedure Call= ), if there were not a terminology definition telling me that I should not = misinterpret the word in this manner. I believe it is problematic to select a term that is so commonly used in th= e industry, and provide it with a definition that is not consistent with th= at common usage. I believe the term could easily be replaced by: MA Configuration: The description of Measurement Tasks to perform and th= e details of the Report to send. The MA Configuration is sent by a Controller to a Measurement Agent. If we wanted to just call this Configuration, we could then add the sentenc= e: Also simply referred to as "Configuration" where the context is clear. Barbara From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Tuesday, September 17, 2013 5:59 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Thanks Barbara. thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. Not sure I fully understood your point about Instruction. I was trying to use it as defined in the terminology <> The Instruction would be a message with - one of more Measurement Tasks - one of more Schedules - one or more Report Channels I guess the first msg from Controller to MA includes all of these. Subseque= nt msgs might only update one of them, for instance the Schedule might get = updated rather more often than the other two items. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 12 September 2013 19:34 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_9966516C6EB5FC4381E05BF80AA55F771E33B3US70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil=

 

If the definition of I= nstruction was limited to MA Configuration (which in the current definition= it seems to be) then Barbara’s definition is more clear.<= /span>

 

BR,<= /p>

Tim<= /p>

 

From: philip.e= ardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Tuesday, September 17, 2013 11:16 AM
To: bs7652@att.com; lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

What do other p= eople think?

I don’t h= ave a strong feeling either way.

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: 17 September 2013 14:51
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

I see that your use of= “Instruction” is consistent with its proposed LMAP terminology= definition. And I have no problem with there being a term with that defini= tion.

 

It would appear that m= y problem is with the choice of “Instruction” as the word to ap= ply this definition to.

 

The proposed terminolo= gy definition uses “Instruction” in a manner that I don’t= consider completely consistent with the way I generally use the word.=

In computing, “I= nstruction” is a very basic, low-level message. Such a message tells = the computer to do something very specific. There are many, many instructio= ns in a computer’s “instruction set”.

I’ve also seen t= his term used with other inter-device communication. As with computing R= 20;instructions”, this sort of communication has many different types= of messages, such that each desired action has its own “instruction”.

In the absence of actu= ally reading the lmap terminology definition, and forcing myself to accept = that lmap is using this word in what I consider an industry-inconsistent wa= y, I would misinterpret the use of this word (and did in fact misinterpret it).

For me, “instruc= tion” in the context of some of the xml-based WAN configuration proto= cols we’re looking at, would map to an RPC (Remote Procedure Call), i= f there were not a terminology definition telling me that I should not misinterpret the word in this manner.

I believe it is proble= matic to select a term that is so commonly used in the industry, and provid= e it with a definition that is not consistent with that common usage.<= /o:p>

 

I believe the term cou= ld easily be replaced by:

   MA Configuration: The description of Measurem= ent Tasks to perform and the

   details of the Report to send.  The MA C= onfiguration is sent by a

   Controller to a Measurement Agent.

 

If we wanted to just c= all this Configuration, we could then add the sentence:

Also simply referred to as “Configuration” whe= re the context is clear.

 

Barbara

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Tuesday, September 17, 2013 5:59 AM
To: STARK, BARBARA H; lmap@ietf.org=
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

Thanks Barbara.=

thinking about = your process question – we’re now trying to write a ‘prot= ocol model’ for the framework doc (rfc4101) – so the protocol w= ill be described at this level.

 

Not sure I full= y understood your point about Instruction.

I was trying to= use it as defined in the terminology

<<=
Instruction: The description o=
f Measurement Tasks to perform and the

  = ; details of the Report to send.  The Instruction is sent by a

  = ; Controller to a Measurement Agent.

>> = ;

 <= /span>

The Instruction wo= uld be a message with

-one of mor= e Measurement Tasks

-one of mor= e Schedules

-one or mor= e Report Channels

I guess the first = msg from Controller to MA includes all of these. Subsequent msgs might only= update one of them, for instance the Schedule might get updated rather more often than the other two items.

 <= /span>

  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =    

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: 12 September 2013 19:34
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

First a process questi= on:

How detailed is this F= ramework document supposed to be? Is it intended to include the full list o= f criteria for a Control Protocol, or will these criteria be documented sep= arately? If the first, then I would prefer for the criteria to be more precisely described, and easy to identi= fy as Control Protocol criteria/requirements. If the latter, then I would p= refer for the Framework to use more descriptive language as to what is expe= cted of the Control Protocol, rather than trying to give names to all of the various expected functionality (e.= g., Instruction, registration). More detailed comments below.

Barbara

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Thursday, September 12, 2013 11:45 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions betwee= n MA and Controller

 

Thanks for the nice d= iscussion, I’ve tried to re-write to reflect where I think we’v= e got to. I also changed the title to:

 

Interactions between = MA and Controller

As part of a bootstra= p process the MA gets sufficient information to contact a Controller. Defin= ing a bootstrap mechanism is out of scope of the LMAP WG.=

 

The basic interaction= between a Controller and MA is that the Controller sends an Instruction to= the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect that= the measurement system understands what Measurement Methods the MA can do = and therefore the Controller can simply instruct the MA; there is no need f= or a negotiation protocol (which would add complexity to the MA, Controller and Control Protocol). However,= it is possible that the MA is in fact not capable of performing the reques= ted Measurement Method, and so the Control Protocol must allow the MA to re= ply with a suitable error code.

&n= bsp;

<bhs= > The use of the word “Instruction” here makes me uncomforta= ble, because it implies (at least to me) a manner of communication that is = not quite consistent with the way most WAN-based massive-number-of-controll= ed-devices control protocols work today. “Instruction” suggests a manner = of communication where the desired action is a part of the basic message. H= aving separate message syntax (actions) for everything the Controller wants= the MA to do would greatly increase the number of messages that need to go back and forth between MA and controller. This= sort of interaction is common in protocols intended to work on LAN segment= s. It’s a very bad idea for protocols intended to work over the WAN t= hat are intended to scale to large numbers of devices, and be highly extensible. I would prefer if we did not attempt= to give this function of the Controller to MA interaction a proper name (d= enoted by a capital first letter). I would also prefer if we described it a= s “the Controller configures the MA”, using the word “configure” instead of “instru= ct”.

&n= bsp;

I don&#= 8217;t think we’ve defined “negotiation protocol”. Probab= ly because we don’t need it. I would prefer if we got rid of that (ne= gotiation protocol) sentence and just used the last sentence as a positive statement about what we do expect from the Control Protocol. For example: = The Control Protocol must support robust error reporting by the MA, to prov= ide the Controller with sufficiently-detailed reasons for any failures in c= onfiguration.

&n= bsp;

Is R= 20;measurement system” defined? I’m a bit unclear on what this = is.

&n= bsp;

Resulti= ng recommended text:

The bas= ic interaction between a Controller and MA is that the Controller configure= s the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect t= hat the Controller knows what Measurement Methods the MA supports, such tha= t the Controller can correctly configure the MA. However, the Control Proto= col must support robust error reporting by the MA, to provide the Controller with sufficiently-detailed reasons fo= r any failures in configuration.

 

The MA can send to th= e Controller the list of Measurement Methods that it is capable of. This co= uld be useful:

[1] as part of the MA= registering with the Controller. Note that in some scenarios it is not nee= ded, as the Controller will know the information by other means, for example as part of the bootstrapping process (using Tr-069 say)= or because the MA is statically configured.

[2] so the MA can re-= register, for example if it becomes capable of a new Measurement Method.

** Comment: suggest w= e keep it simple and just send the complete list, rather than a delta. The = message should be short, since Methods are referred to via a registry.

[3] when requested by= the Controller, which could be useful if ‘something goes wrong’= ; and the Controller forgets what the MA can do.

&n= bsp;

<bhs= > The word “register” also makes me uncomfortable, though no= t as much as “Instruct”. This implies to me some very specific = functionality than I don’t consider completely necessary. But maybe if “registration” were defined I would feel better about it. T= he “**Comment” suggestion is too specific for the Framework, IM= O. But if Framework has detailed Control Protocol criteria, then I would re= word the statement as “The Control Protocol must allow the Controller to request the MA supply the MA’s complete list of suppor= ted Measurement Methods, in a concise format.”  I would prefer i= f the above statements were reworded as:

The MA = can send to the Controller the list of Measurement Methods that it is capab= le of. This could be useful:

[1] whe= n the MA first communicates with a Controller.

[2] whe= n the MA becomes capable of a new Measurement Method.

[3] whe= n requested by the Controller (e.g., if the Controller forgets what the MA = can do or otherwise wants to resynchronize what it knows about the MA).

 

Note that the advert = contains the list of Measurement Methods that the MA can perform. It is not= intended to indicate dynamic capabilities like the MA’s currently unused CPU, memory or battery life.

** Comment: I’m= not sure whether we reached consensus on this point.

&n= bsp;

<bhs= > I would have no objection to including such capabilities as optional e= lements of the information model. In fact, I think it would be a good idea.= But I don’t think this needs to be mentioned in the Framework.

 

It is possible that l= ater, when a MA is implementing the Instruction, it does not perform a part= icular Measurement Task for some reason, such as: the Measurement Peer is busy, or there is cross-traffic, … The MA doesn’t info= rm the Controller, instead it is reported to the Collector as part of the M= easurement Report. The Collector may in turn tell the measurement system or= even the Controller, but this is out of scope of LMAP.

** Comment: are there= any conditions when it’s critical for the Controller to be informed?=

&n= bsp;

<bhs= > Ditto my previous objection to “Instruction”. I believe th= e information model needs to include status parameters that would allow the= Controller to request this info, at some level. This can be optional to support for MA and Controller. I recommend rewording to:

It is p= ossible that an MA is unable to carry out a configured Measurement Task. Po= ssible reasons include the Measurement Peer being busy, presence of cross-traffic, … The MA will report this information to the Colle= ctor as part of the Measurement Report. The Collector may in turn tell othe= r systems (including, possibly, the Controller), but this is out of scope o= f LMAP. The MA may also be able to inform the Controller directly of such occurrences.

&n= bsp;

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 05 September 2013 11:13
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 No negotiation between MA an= d Controller

 

Another issue:

There is no negotiati= on between the MA and Controller - the Controller simply sends the Instruct= ion to the MA, with the details of the Measurement Tasks to perform.

In general we expect = that the measurement system understands the capabilities of its MAs (probab= ly there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. It would also= add complexity to the MA, Controller and Control Protocol.

 

It is possible that t= he MA can’t perform the requested Measurement Task. So the Control Pr= otocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to se= nd a list of all the Measurement Methods that it is capable of, in case = 216;something goes wrong’ and the Controller forgets what the MA can = do. Comment: this idea hasn’t had much discussion yet, but appears in the Information Model i-d

 

Thoughts?

Thanks

phil

--_000_9966516C6EB5FC4381E05BF80AA55F771E33B3US70UWXCHMBA05zam_-- From dromasca@avaya.com Tue Sep 17 08:22:35 2013 Return-Path: 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 6519611E8491 for ; Tue, 17 Sep 2013 08:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.988 X-Spam-Level: X-Spam-Status: No, score=-103.988 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 xK+ORoBrq44L for ; Tue, 17 Sep 2013 08:22:26 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id BA3BD11E8474 for ; Tue, 17 Sep 2013 08:22:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAAVyOFLGmAcV/2dsb2JhbABRCoJDIyE4UsEegR0WdIIlAQEBAQMSCBNcAgEIDQQEAQELFgEGBzIUCQgBAQQBEggRCYdhAZ4enAMXjhgMgQwGBgcqAQIEgxiBAAOeUosdgWaBPoIq X-IronPort-AV: E=Sophos;i="4.90,923,1371096000"; d="scan'208,217";a="24270328" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Sep 2013 11:22:03 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Sep 2013 11:19:24 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Tue, 17 Sep 2013 17:22:00 +0200 From: "Romascanu, Dan (Dan)" To: "philip.eardley@bt.com" , "bs7652@att.com" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAAD0AhwAAAihGA= Date: Tue, 17 Sep 2013 15:22:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA128DC22DAZFFEXMB04globa_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:22:35 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA128DC22DAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Neither do I (feel strongly either way). However I believe that Configurati= on risks to be also mis-leading, and not consistent with other usages of th= e term in the industry (or on the MA or the MA host). What about "Procedure= " or "MA Procedure"? Dan (speaking as contributor) From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: Tuesday, September 17, 2013 5:16 PM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller What do other people think? I don't have a strong feeling either way. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 September 2013 14:51 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller I see that your use of "Instruction" is consistent with its proposed LMAP t= erminology definition. And I have no problem with there being a term with t= hat definition. It would appear that my problem is with the choice of "Instruction" as the = word to apply this definition to. The proposed terminology definition uses "Instruction" in a manner that I d= on't consider completely consistent with the way I generally use the word. In computing, "Instruction" is a very basic, low-level message. Such a mess= age tells the computer to do something very specific. There are many, many = instructions in a computer's "instruction set". I've also seen this term used with other inter-device communication. As wit= h computing "instructions", this sort of communication has many different t= ypes of messages, such that each desired action has its own "instruction". In the absence of actually reading the lmap terminology definition, and for= cing myself to accept that lmap is using this word in what I consider an in= dustry-inconsistent way, I would misinterpret the use of this word (and did= in fact misinterpret it). For me, "instruction" in the context of some of the xml-based WAN configura= tion protocols we're looking at, would map to an RPC (Remote Procedure Call= ), if there were not a terminology definition telling me that I should not = misinterpret the word in this manner. I believe it is problematic to select a term that is so commonly used in th= e industry, and provide it with a definition that is not consistent with th= at common usage. I believe the term could easily be replaced by: MA Configuration: The description of Measurement Tasks to perform and th= e details of the Report to send. The MA Configuration is sent by a Controller to a Measurement Agent. If we wanted to just call this Configuration, we could then add the sentenc= e: Also simply referred to as "Configuration" where the context is clear. Barbara From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Tuesday, September 17, 2013 5:59 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Thanks Barbara. thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. Not sure I fully understood your point about Instruction. I was trying to use it as defined in the terminology <> The Instruction would be a message with - one of more Measurement Tasks - one of more Schedules - one or more Report Channels I guess the first msg from Controller to MA includes all of these. Subseque= nt msgs might only update one of them, for instance the Schedule might get = updated rather more often than the other two items. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 12 September 2013 19:34 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_9904FB1B0159DA42B0B887B7FA8119CA128DC22DAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Neither do I (feel str= ongly either way). However I believe that Configuration risks to be also mi= s-leading, and not consistent with other usages of the term in the industry= (or on the MA or the MA host). What about “Procedure” or “MA Procedure”?

 

Dan<= /p>

(speaking as contribut= or)

 

 

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Tuesday, September 17, 2013 5:16 PM
To: bs7652@att.com; lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

What do other p= eople think?

I don’t h= ave a strong feeling either way.

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: 17 September 2013 14:51
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

I see that your use of= “Instruction” is consistent with its proposed LMAP terminology= definition. And I have no problem with there being a term with that defini= tion.

 

It would appear that m= y problem is with the choice of “Instruction” as the word to ap= ply this definition to.

 

The proposed terminolo= gy definition uses “Instruction” in a manner that I don’t= consider completely consistent with the way I generally use the word.=

In computing, “I= nstruction” is a very basic, low-level message. Such a message tells = the computer to do something very specific. There are many, many instructio= ns in a computer’s “instruction set”.

I’ve also seen t= his term used with other inter-device communication. As with computing R= 20;instructions”, this sort of communication has many different types= of messages, such that each desired action has its own “instruction”.

In the absence of actu= ally reading the lmap terminology definition, and forcing myself to accept = that lmap is using this word in what I consider an industry-inconsistent wa= y, I would misinterpret the use of this word (and did in fact misinterpret it).

For me, “instruc= tion” in the context of some of the xml-based WAN configuration proto= cols we’re looking at, would map to an RPC (Remote Procedure Call), i= f there were not a terminology definition telling me that I should not misinterpret the word in this manner.

I believe it is proble= matic to select a term that is so commonly used in the industry, and provid= e it with a definition that is not consistent with that common usage.<= /o:p>

 

I believe the term cou= ld easily be replaced by:

   MA Configuration: The description of Measurem= ent Tasks to perform and the

   details of the Report to send.  The MA C= onfiguration is sent by a

   Controller to a Measurement Agent.

 

If we wanted to just c= all this Configuration, we could then add the sentence:

Also simply referred to as “Configuration” whe= re the context is clear.

 

Barbara

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Tuesday, September 17, 2013 5:59 AM
To: STARK, BARBARA H; lmap@ietf.org=
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

Thanks Barbara.=

thinking about = your process question – we’re now trying to write a ‘prot= ocol model’ for the framework doc (rfc4101) – so the protocol w= ill be described at this level.

 

Not sure I full= y understood your point about Instruction.

I was trying to= use it as defined in the terminology

<<=
Instruction: The description o=
f Measurement Tasks to perform and the

  = ; details of the Report to send.  The Instruction is sent by a

  = ; Controller to a Measurement Agent.

>> = ;

 <= /span>

The Instruction wo= uld be a message with

-one of more Measurement Tasks

-one of more Schedules

-one or more Report Channels

I guess the first = msg from Controller to MA includes all of these. Subsequent msgs might only= update one of them, for instance the Schedule might get updated rather more often than the other two items.

 <= /span>

  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =    

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: 12 September 2013 19:34
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

First a process questi= on:

How detailed is this F= ramework document supposed to be? Is it intended to include the full list o= f criteria for a Control Protocol, or will these criteria be documented sep= arately? If the first, then I would prefer for the criteria to be more precisely described, and easy to identi= fy as Control Protocol criteria/requirements. If the latter, then I would p= refer for the Framework to use more descriptive language as to what is expe= cted of the Control Protocol, rather than trying to give names to all of the various expected functionality (e.= g., Instruction, registration). More detailed comments below.

Barbara

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Thursday, September 12, 2013 11:45 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions betwee= n MA and Controller

 

Thanks for the nice d= iscussion, I’ve tried to re-write to reflect where I think we’v= e got to. I also changed the title to:

 

Interactions between = MA and Controller

As part of a bootstra= p process the MA gets sufficient information to contact a Controller. Defin= ing a bootstrap mechanism is out of scope of the LMAP WG.=

 

The basic interaction= between a Controller and MA is that the Controller sends an Instruction to= the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect that= the measurement system understands what Measurement Methods the MA can do = and therefore the Controller can simply instruct the MA; there is no need f= or a negotiation protocol (which would add complexity to the MA, Controller and Control Protocol). However,= it is possible that the MA is in fact not capable of performing the reques= ted Measurement Method, and so the Control Protocol must allow the MA to re= ply with a suitable error code.

&n= bsp;

<bhs= > The use of the word “Instruction” here makes me uncomforta= ble, because it implies (at least to me) a manner of communication that is = not quite consistent with the way most WAN-based massive-number-of-controll= ed-devices control protocols work today. “Instruction” suggests a manner = of communication where the desired action is a part of the basic message. H= aving separate message syntax (actions) for everything the Controller wants= the MA to do would greatly increase the number of messages that need to go back and forth between MA and controller. This= sort of interaction is common in protocols intended to work on LAN segment= s. It’s a very bad idea for protocols intended to work over the WAN t= hat are intended to scale to large numbers of devices, and be highly extensible. I would prefer if we did not attempt= to give this function of the Controller to MA interaction a proper name (d= enoted by a capital first letter). I would also prefer if we described it a= s “the Controller configures the MA”, using the word “configure” instead of “instru= ct”.

&n= bsp;

I don&#= 8217;t think we’ve defined “negotiation protocol”. Probab= ly because we don’t need it. I would prefer if we got rid of that (ne= gotiation protocol) sentence and just used the last sentence as a positive statement about what we do expect from the Control Protocol. For example: = The Control Protocol must support robust error reporting by the MA, to prov= ide the Controller with sufficiently-detailed reasons for any failures in c= onfiguration.

&n= bsp;

Is R= 20;measurement system” defined? I’m a bit unclear on what this = is.

&n= bsp;

Resulti= ng recommended text:

The bas= ic interaction between a Controller and MA is that the Controller configure= s the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect t= hat the Controller knows what Measurement Methods the MA supports, such tha= t the Controller can correctly configure the MA. However, the Control Proto= col must support robust error reporting by the MA, to provide the Controller with sufficiently-detailed reasons fo= r any failures in configuration.

 

The MA can send to th= e Controller the list of Measurement Methods that it is capable of. This co= uld be useful:

[1] as part of the MA= registering with the Controller. Note that in some scenarios it is not nee= ded, as the Controller will know the information by other means, for example as part of the bootstrapping process (using Tr-069 say)= or because the MA is statically configured.

[2] so the MA can re-= register, for example if it becomes capable of a new Measurement Method.

** Comment: suggest w= e keep it simple and just send the complete list, rather than a delta. The = message should be short, since Methods are referred to via a registry.

[3] when requested by= the Controller, which could be useful if ‘something goes wrong’= ; and the Controller forgets what the MA can do.

&n= bsp;

<bhs= > The word “register” also makes me uncomfortable, though no= t as much as “Instruct”. This implies to me some very specific = functionality than I don’t consider completely necessary. But maybe if “registration” were defined I would feel better about it. T= he “**Comment” suggestion is too specific for the Framework, IM= O. But if Framework has detailed Control Protocol criteria, then I would re= word the statement as “The Control Protocol must allow the Controller to request the MA supply the MA’s complete list of suppor= ted Measurement Methods, in a concise format.”  I would prefer i= f the above statements were reworded as:

The MA = can send to the Controller the list of Measurement Methods that it is capab= le of. This could be useful:

[1] whe= n the MA first communicates with a Controller.

[2] whe= n the MA becomes capable of a new Measurement Method.

[3] whe= n requested by the Controller (e.g., if the Controller forgets what the MA = can do or otherwise wants to resynchronize what it knows about the MA).

 

Note that the advert = contains the list of Measurement Methods that the MA can perform. It is not= intended to indicate dynamic capabilities like the MA’s currently unused CPU, memory or battery life.

** Comment: I’m= not sure whether we reached consensus on this point.

&n= bsp;

<bhs= > I would have no objection to including such capabilities as optional e= lements of the information model. In fact, I think it would be a good idea.= But I don’t think this needs to be mentioned in the Framework.

 

It is possible that l= ater, when a MA is implementing the Instruction, it does not perform a part= icular Measurement Task for some reason, such as: the Measurement Peer is busy, or there is cross-traffic, … The MA doesn’t info= rm the Controller, instead it is reported to the Collector as part of the M= easurement Report. The Collector may in turn tell the measurement system or= even the Controller, but this is out of scope of LMAP.

** Comment: are there= any conditions when it’s critical for the Controller to be informed?=

&n= bsp;

<bhs= > Ditto my previous objection to “Instruction”. I believe th= e information model needs to include status parameters that would allow the= Controller to request this info, at some level. This can be optional to support for MA and Controller. I recommend rewording to:

It is p= ossible that an MA is unable to carry out a configured Measurement Task. Po= ssible reasons include the Measurement Peer being busy, presence of cross-traffic, … The MA will report this information to the Colle= ctor as part of the Measurement Report. The Collector may in turn tell othe= r systems (including, possibly, the Controller), but this is out of scope o= f LMAP. The MA may also be able to inform the Controller directly of such occurrences.

&n= bsp;

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 05 September 2013 11:13
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 No negotiation between MA an= d Controller

 

Another issue:

There is no negotiati= on between the MA and Controller - the Controller simply sends the Instruct= ion to the MA, with the details of the Measurement Tasks to perform.

In general we expect = that the measurement system understands the capabilities of its MAs (probab= ly there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. It would also= add complexity to the MA, Controller and Control Protocol.

 

It is possible that t= he MA can’t perform the requested Measurement Task. So the Control Pr= otocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to se= nd a list of all the Measurement Methods that it is capable of, in case = 216;something goes wrong’ and the Controller forgets what the MA can = do. Comment: this idea hasn’t had much discussion yet, but appears in the Information Model i-d

 

Thoughts?

Thanks

phil

--_000_9904FB1B0159DA42B0B887B7FA8119CA128DC22DAZFFEXMB04globa_-- From j.schoenwaelder@jacobs-university.de Tue Sep 17 08:22:50 2013 Return-Path: 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 6550511E8281 for ; Tue, 17 Sep 2013 08:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 D06R0eawyDjU for ; Tue, 17 Sep 2013 08:22:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DFEC511E836B for ; Tue, 17 Sep 2013 08:22:35 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDCA520BEB; Tue, 17 Sep 2013 17:22:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kfm5PQ1a60FR; Tue, 17 Sep 2013 17:22:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 423B120BE5; Tue, 17 Sep 2013 17:22:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1C350286649C; Tue, 17 Sep 2013 17:22:24 +0200 (CEST) Date: Tue, 17 Sep 2013 17:22:23 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20130917152223.GA44479@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:22:50 -0000 On Tue, Sep 17, 2013 at 01:51:24PM +0000, STARK, BARBARA H wrote: > I see that your use of "Instruction" is consistent with its proposed LMAP terminology definition. And I have no problem with there being a term with that definition. > > It would appear that my problem is with the choice of "Instruction" as the word to apply this definition to. > > The proposed terminology definition uses "Instruction" in a manner that I don't consider completely consistent with the way I generally use the word. > In computing, "Instruction" is a very basic, low-level message. Such a message tells the computer to do something very specific. There are many, many instructions in a computer's "instruction set". > I've also seen this term used with other inter-device communication. As with computing "instructions", this sort of communication has many different types of messages, such that each desired action has its own "instruction". > In the absence of actually reading the lmap terminology definition, and forcing myself to accept that lmap is using this word in what I consider an industry-inconsistent way, I would misinterpret the use of this word (and did in fact misinterpret it). > For me, "instruction" in the context of some of the xml-based WAN configuration protocols we're looking at, would map to an RPC (Remote Procedure Call), if there were not a terminology definition telling me that I should not misinterpret the word in this manner. > I believe it is problematic to select a term that is so commonly used in the industry, and provide it with a definition that is not consistent with that common usage. > > I believe the term could easily be replaced by: > MA Configuration: The description of Measurement Tasks to perform and the > details of the Report to send. The MA Configuration is sent by a > Controller to a Measurement Agent. > > If we wanted to just call this Configuration, we could then add the sentence: > Also simply referred to as "Configuration" where the context is clear. MA Configuration seems too broad to me given the current definition of Instruction: Instruction: The description of Measurement Tasks to perform and the details of the Report to send. The Instruction is sent by a Controller to a Measurement Agent. In other words, Instruction, as currently defined, is the subset of the MA Configuration pertaining to Measurement Tasks and the Reports. An unwieldy long term like 'Measurement Task and Report Configuration' would be more precise but not very practical. So yes, Instruction may not be ideal but so far I have not seen a good counter proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From philip.eardley@bt.com Tue Sep 17 08:23:37 2013 Return-Path: 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 6A2A311E8283 for ; Tue, 17 Sep 2013 08:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.294 X-Spam-Level: X-Spam-Status: No, score=-104.294 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 nFmoT8woEMsl for ; Tue, 17 Sep 2013 08:23:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 3457011E829D for ; Tue, 17 Sep 2013 08:23:24 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 17 Sep 2013 16:23:16 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Tue, 17 Sep 2013 16:23:16 +0100 From: To: , , Date: Tue, 17 Sep 2013 16:23:15 +0100 Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAABCDBQAALRWlA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518A2BEMV67UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:23:37 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518A2BEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thinking about this more there seem several cases: 1. the MA cannot action the Instruction (for example, it doesn't include= a parameter that is mandatory for the requested Measurement Method); 2. the Measurement Task could not be executed (for example, the MA unexp= ectedly has no spare CPU cycles). 3. the Measurement Task executes but (correctly) no test traffic is sent= - a "pre-check test" - for example if the MA detects cross-traffic discussing with trevor - it seems to make sense if 1 & 2 are reported by th= e MA to the Controller (don't want them polluting your measurement results)= , whilst 3 is reported by the MA to the Collector (as part of a normal Repo= rt). Expanding on 1: no value for a mandatory parameter time of test is in past type wrong, eg string given where expect integer Schedule refers to a Measurement configuration or Report Channel that doesn= 't exist Expanding on 2: MA has crashed MA doesn't (any longer) understand requested Method MA has run out of CPU, memory, battery power Collector has disappeared MP has disappeared From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] Sent: 17 September 2013 15:01 To: 'STARK, BARBARA H'; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Adding a bit to some of Barbara's input What should be passed to a MA 1) Schedule to initiate testing 2) Policy of what testing to accept (who, what type, ....) The big question I have is when does a MA check it's test schedule to see i= f can actually handle it. I would expect that a) The MA do a cursory test capability check on it's test schedule to = make sure it can do a test - IF NOT it should reject it (not a negotiation = but a "accept / reject") Again this is to fix the "I thought everything was running ok" issue. When Op's sets up a test to run overnight only to fin= d out the bulk of the test points couldn't run it .... May be the last tim= e they use that system. b) The MA does a resource check to approve or deny a test once the tim= e to test (schedule) is reached - I'm saying it should do test call admissi= on pre-test-flight checks and then permit or deny the Test initiation. From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STA= RK, BARBARA H Sent: Tuesday, September 17, 2013 8:51 AM To: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller I see that your use of "Instruction" is consistent with its proposed LMAP t= erminology definition. And I have no problem with there being a term with t= hat definition. It would appear that my problem is with the choice of "Instruction" as the = word to apply this definition to. The proposed terminology definition uses "Instruction" in a manner that I d= on't consider completely consistent with the way I generally use the word. In computing, "Instruction" is a very basic, low-level message. Such a mess= age tells the computer to do something very specific. There are many, many = instructions in a computer's "instruction set". I've also seen this term used with other inter-device communication. As wit= h computing "instructions", this sort of communication has many different t= ypes of messages, such that each desired action has its own "instruction". In the absence of actually reading the lmap terminology definition, and for= cing myself to accept that lmap is using this word in what I consider an in= dustry-inconsistent way, I would misinterpret the use of this word (and did= in fact misinterpret it). For me, "instruction" in the context of some of the xml-based WAN configura= tion protocols we're looking at, would map to an RPC (Remote Procedure Call= ), if there were not a terminology definition telling me that I should not = misinterpret the word in this manner. I believe it is problematic to select a term that is so commonly used in th= e industry, and provide it with a definition that is not consistent with th= at common usage. I believe the term could easily be replaced by: MA Configuration: The description of Measurement Tasks to perform and th= e details of the Report to send. The MA Configuration is sent by a Controller to a Measurement Agent. If we wanted to just call this Configuration, we could then add the sentenc= e: Also simply referred to as "Configuration" where the context is clear. Barbara From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Tuesday, September 17, 2013 5:59 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Thanks Barbara. thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. Not sure I fully understood your point about Instruction. I was trying to use it as defined in the terminology <> The Instruction would be a message with - one of more Measurement Tasks - one of more Schedules - one or more Report Channels I guess the first msg from Controller to MA includes all of these. Subseque= nt msgs might only update one of them, for instance the Schedule might get = updated rather more often than the other two items. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 12 September 2013 19:34 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518A2BEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thinking about= this more there seem several cases:

 

 <= /span>

1.<= span style=3D'font:7.0pt "Times New Roman"'>    the MA cannot action the Instruction (for example, it = doesn't include a parameter that is mandatory for the requested Measurement= Method);

2. &= nbsp;  the Measurement Task could not= be executed (for example, the MA unexpectedly has no spare CPU cycles).

3.    the Measurement Task executes but (correctly= ) no test traffic is sent – a “pre-check test” - for exam= ple if the MA detects cross-traffic

 

discussing with tre= vor – it seems to make sense if 1 & 2 are reported by the MA to t= he Controller (don’t want them polluting your measurement results), w= hilst 3 is reported by the MA to the Collector (as part of a normal Report)= .

 

<= p class=3DMsoNormal>Expanding on 1:

no value for a mandatory parameter

time of test is in past

type wrong, eg string given where expect integer

<= p class=3DMsoNormal>Schedule refers to a Measurement configuration or Rep= ort Channel that doesn't exist

=  

Expanding on 2:

MA has crashed

MA doesn’t (any longer) understand requested Meth= od

MA has run out of CPU, memor= y, battery power

Collector has = disappeared

MP has disappeared<= o:p>

 

 

From: Bugenhagen, Michael K [mailto:= Michael.K.Bugenhagen@centurylink.com]
Sent: 17 September 2013 15= :01
To: 'STARK, BARBARA H'; Eardley,PL,Philip,TUB8 R; lmap@ietf.o= rg
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interacti= ons between MA and Controller

 

Adding a bit to some of Barbara’s input=

=  

What should be passed to a MA

1) = ;     Schedule to initiate testing

=

2)=       Policy of what testing to accept (who, what t= ype, ….)

 

<= span lang=3DEN-US style=3D'color:#1F497D'>The big question I have is when d= oes a MA check it’s test schedule to see if can actually handle it.

I would expect that

a) = ;     The MA do a cursory test capability check on it= 217;s test schedule to make sure it can do a test – IF NOT it should = reject it (not a negotiation but a “accept / reject”)

      Again t= his is to fix the “I thought everything was running ok” issue.<= o:p>

     = ;            &n= bsp;    When Op’s sets up a test to run overnight only= to find out the bulk of the test points couldn’t run it ….&nbs= p; May be the last time they use that system.

 

b) &= nbsp;    The MA does a resource check to approve or deny a te= st once the time to test (schedule) is reached – I’m saying it = should do test call admission pre-test-flight checks and then permit or den= y the

   &nbs= p;  Test initiation.

 

 <= /p>

&nb= sp;

 

 

=  

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H
Sent: Tuesday, September 17, 2013 8:51 AM
To: philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap]= LMAP Framework issue #3 (take 2) Interactions between MA and Controller

 

I see that your use of “Instruction” is consistent= with its proposed LMAP terminology definition. And I have no problem with = there being a term with that definition.

 

It wou= ld appear that my problem is with the choice of “Instruction” a= s the word to apply this definition to.

 <= /p>

The prop= osed terminology definition uses “Instruction” in a manner that= I don’t consider completely consistent with the way I generally use = the word.

In computing, “Instruction” is a very basic= , low-level message. Such a message tells the computer to do something very= specific. There are many, many instructions in a computer’s “i= nstruction set”.

I’ve also seen this term used with o= ther inter-device communication. As with computing “instructions̶= 1;, this sort of communication has many different types of messages, such t= hat each desired action has its own “instruction”.

In= the absence of actually reading the lmap terminology definition, and forci= ng myself to accept that lmap is using this word in what I consider an indu= stry-inconsistent way, I would misinterpret the use of this word (and did i= n fact misinterpret it).

For me, “instruction” in the= context of some of the xml-based WAN configuration protocols we’re l= ooking at, would map to an RPC (Remote Procedure Call), if there were not a= terminology definition telling me that I should not misinterpret the word = in this manner.

I believe it is problematic to select a term tha= t is so commonly used in the industry, and provide it with a definition tha= t is not consistent with that common usage.

 

I = believe the term could easily be replaced by:

   MA Configuration: The description of Measurement Tas= ks to perform and the

   = details of the Report to send.  The MA Configuration is sent by a=

   Controller to a Measurement= Agent.

 

If we want= ed to just call this Configuration, we could then add the sentence:

Also simply referred to as “Configura= tion” where the context is clear.

 <= /p>

Barbara =

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Tuesday, Sep= tember 17, 2013 5:59 AM
To: STARK, BARBARA H; lmap@ietf.org
Subject: RE: [lmap] LMAP Framewor= k issue #3 (take 2) Interactions between MA and Controller

 <= /span>

Thanks Barbara.

thinking about your process question – we’re = now trying to write a ‘protocol model’ for the framework doc (r= fc4101) – so the protocol will be described at this level.

 

Not sure I fully understood your point about Instruction.

I was trying to use it as defined in = the terminology

<<Instruction: The description o=
f Measurement Tasks to perform and the

   details of the Report to = send.  The Instruction is sent by a

   Controller to a Measureme= nt Agent.

>><= o:p> 

 

The Instruction would be a me= ssage with

-       one of more Measurement Tasks

-       one of more Schedules

-     &nbs= p; one or more Report Channels

I guess the first msg = from Controller to MA includes all of these. Subsequent msgs might only upd= ate one of them, for instance the Schedule might get updated rather more of= ten than the other two items.

 

  &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;   

From: STARK, BARBARA H [mailto:bs7652@att.com]
Sent: 12 September 20= 13 19:34
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: [lmap] LMAP Framework issue= #3 (take 2) Interactions between MA and Controller

 

First a process question:

How detailed is this Framework document supposed to be? Is it intended to= include the full list of criteria for a Control Protocol, or will these cr= iteria be documented separately? If the first, then I would prefer for the = criteria to be more precisely described, and easy to identify as Control Pr= otocol criteria/requirements. If the latter, then I would prefer for the Fr= amework to use more descriptive language as to what is expected of the Cont= rol Protocol, rather than trying to give names to all of the various expect= ed functionality (e.g., Instruction, registration). More detailed comments = below.

Barbara

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Se= nt: Thursday, September 12, 2013 11:45 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Framewor= k issue #3 (take 2) Interactions between MA and Controller

 <= /span>

Thanks for the nice discussion, I’ve tried= to re-write to reflect where I think we’ve got to. I also changed th= e title to:

 <= /p>

Interactions between MA and Controller

As part of a bootstrap process the MA gets sufficient= information to contact a Controller. Defining a bootstrap mechanism is out= of scope of the LMAP WG.

 =

The basic interaction between a Controlle= r and MA is that the Controller sends an Instruction to the MA, detailing w= hat Measurement Tasks to do, when to do them, and how to report the Measure= ment Results. In general we expect that the measurement system understands = what Measurement Methods the MA can do and therefore the Controller can sim= ply instruct the MA; there is no need for a negotiation protocol (which wou= ld add complexity to the MA, Controller and Control Protocol). However, it = is possible that the MA is in fact not capable of performing the requested = Measurement Method, and so the Control Protocol must allow the MA to reply = with a suitable error code.

 

= <bhs> The use of the word “Instru= ction” here makes me uncomfortable, because it implies (at least to m= e) a manner of communication that is not quite consistent with the way most= WAN-based massive-number-of-controlled-devices control protocols work toda= y. “Instruction” suggests a manner of communication where the d= esired action is a part of the basic message. Having separate message synta= x (actions) for everything the Controller wants the MA to do would greatly = increase the number of messages that need to go back and forth between MA a= nd controller. This sort of interaction is common in protocols intended to = work on LAN segments. It’s a very bad idea for protocols intended to = work over the WAN that are intended to scale to large numbers of devices, a= nd be highly extensible. I would prefer if we did not attempt to give this = function of the Controller to MA interaction a proper name (denoted by a ca= pital first letter). I would also prefer if we described it as “the C= ontroller configures the MA”, using the word “configure” = instead of “instruct”.

 

I don’t think we’ve define= d “negotiation protocol”. Probably because we don’t need = it. I would prefer if we got rid of that (negotiation protocol) sentence an= d just used the last sentence as a positive statement about what we do expe= ct from the Control Protocol. For example: The Control Protocol must suppor= t robust error reporting by the MA, to provide the Controller with sufficie= ntly-detailed reasons for any failures in configuration.<= /p>

 

Is “measure= ment system” defined? I’m a bit unclear on what this is.

&nbs= p;

Resul= ting recommended text:

= The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration.

 

<= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>The M= A can send to the Controller the list of Measurement Methods that it is cap= able of. This could be useful:

[1] as= part of the MA registering with the Controller. Note that in some scenario= s it is not needed, as the Controller will know the information by other me= ans, for example as part of the bootstrapping process (using Tr-069 say) or= because the MA is statically configured.

[2] so the MA can re-register, for example if it becomes capable of a = new Measurement Method.

** Comment: = suggest we keep it simple and just send the complete list, rather than a de= lta. The message should be short, since Methods are referred to via a regis= try.

[3] when requested by the Contro= ller, which could be useful if ‘something goes wrong’ and the C= ontroller forgets what the MA can do.

 

<bhs> The word “registe= r” also makes me uncomfortable, though not as much as “Instruct= ”. This implies to me some very specific functionality than I donR= 17;t consider completely necessary. But maybe if “registration”= were defined I would feel better about it. The “**Comment” sug= gestion is too specific for the Framework, IMO. But if Framework has detail= ed Control Protocol criteria, then I would reword the statement as “T= he Control Protocol must allow the Controller to request the MA supply the = MA’s complete list of supported Measurement Methods, in a concise for= mat.”  I would prefer if the above statements were reworded as:<= o:p>

The MA can send to the = Controller the list of Measurement Methods that it is capable of. This coul= d be useful:

[1] when t= he MA first communicates with a Controller.

[2] when the MA becomes capable of a new Measurement= Method.

[3] when requ= ested by the Controller (e.g., if the Controller forgets what the MA can do= or otherwise wants to resynchronize what it knows about the MA).

 

N= ote that the advert contains the list of Measurement Methods that the MA ca= n perform. It is not intended to indicate dynamic capabilities like the MA&= #8217;s currently unused CPU, memory or battery life.

** Comment: I’m not sure whether we reached consens= us on this point.

 

<bhs> I would= have no objection to including such capabilities as optional elements of t= he information model. In fact, I think it would be a good idea. But I don&#= 8217;t think this needs to be mentioned in the Framework.=

 

It is pos= sible that later, when a MA is implementing the Instruction, it does not pe= rform a particular Measurement Task for some reason, such as: the Measureme= nt Peer is busy, or there is cross-traffic, … The MA doesn’t in= form the Controller, instead it is reported to the Collector as part of the= Measurement Report. The Collector may in turn tell the measurement system = or even the Controller, but this is out of scope of LMAP.=

** Comment: are there any conditions when it’s c= ritical for the Controller to be informed?

 

<bhs> Ditto my previous o= bjection to “Instruction”. I believe the information model need= s to include status parameters that would allow the Controller to request t= his info, at some level. This can be optional to support for MA and Control= ler. I recommend rewording to:

It is possible that an MA is unable to carry out a configured Measu= rement Task. Possible reasons include the Measurement Peer being busy, pres= ence of cross-traffic, … The MA will report this information to the C= ollector as part of the Measurement Report. The Collector may in turn tell = other systems (including, possibly, the Controller), but this is out of sco= pe of LMAP. The MA may also be able to inform the Controller directly of su= ch occurrences.

 

&nbs= p;

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf O= f philip.eardley@bt.comSent: 05 September 2013 11:13
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue = #3 No negotiation between MA and Controller

 

Another issue:=

There is no negotiation between the = MA and Controller - the Controller simply sends the Instruction to the MA, = with the details of the Measurement Tasks to perform.

In general we expect that the measurement system understa= nds the capabilities of its MAs (probably there are only one or a few class= es of MA), so negotiation about the MA’s capabilities would have litt= le benefit. It would also add complexity to the MA, Controller and Control = Protocol.

 

It is possible that the MA can’t perform the reque= sted Measurement Task. So the Control Protocol needs to allow the MA to rep= ly with an error code. It has also been suggested that the Controller shoul= d be able to ask the MA to send a list of all the Measurement Methods that = it is capable of, in case ‘something goes wrong’ and the Contro= ller forgets what the MA can do. Comment: this idea hasn’t had much d= iscussion yet, but appears in the Information Model i-d

 

Thoughts? <= o:p>

Thanks

phil

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9518A2BEMV67UKRDdoma_-- From sharam.hakimi@exfo.com Tue Sep 17 08:42:39 2013 Return-Path: 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 11FD211E8110 for ; Tue, 17 Sep 2013 08:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 c6D1PHaweFMX for ; Tue, 17 Sep 2013 08:42:35 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id BECB611E8119 for ; Tue, 17 Sep 2013 08:42:34 -0700 (PDT) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Sep 2013 11:42:33 -0400 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Sep 2013 11:42:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Sep 2013 11:42:22 -0400 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02804EFE@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6zucdcRRahCwBeQGyqyRp2AImMyAAAlEew References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com><2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130917152223.GA44479@elstar.local> From: "Sharam Hakimi" To: "Juergen Schoenwaelder" , "STARK, BARBARA H" X-OriginalArrivalTime: 17 Sep 2013 15:42:32.0773 (UTC) FILETIME=[863D9750:01CEB3BC] Cc: philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:42:39 -0000 Would Command-List be acceptable. The definition would stay the same as it is, just replace instruction with Command-List. Command-List: The description of Measurement Tasks to perform and the details of the Report to send. The Command-List is sent by a Controller to a Measurement Agent. Sharam -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, September 17, 2013 11:22 AM To: STARK, BARBARA H Cc: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller On Tue, Sep 17, 2013 at 01:51:24PM +0000, STARK, BARBARA H wrote: > I see that your use of "Instruction" is consistent with its proposed LMAP terminology definition. And I have no problem with there being a term with that definition. >=20 > It would appear that my problem is with the choice of "Instruction" as the word to apply this definition to. >=20 > The proposed terminology definition uses "Instruction" in a manner that I don't consider completely consistent with the way I generally use the word. > In computing, "Instruction" is a very basic, low-level message. Such a message tells the computer to do something very specific. There are many, many instructions in a computer's "instruction set". > I've also seen this term used with other inter-device communication. As with computing "instructions", this sort of communication has many different types of messages, such that each desired action has its own "instruction". > In the absence of actually reading the lmap terminology definition, and forcing myself to accept that lmap is using this word in what I consider an industry-inconsistent way, I would misinterpret the use of this word (and did in fact misinterpret it). > For me, "instruction" in the context of some of the xml-based WAN configuration protocols we're looking at, would map to an RPC (Remote Procedure Call), if there were not a terminology definition telling me that I should not misinterpret the word in this manner. > I believe it is problematic to select a term that is so commonly used in the industry, and provide it with a definition that is not consistent with that common usage. >=20 > I believe the term could easily be replaced by: > MA Configuration: The description of Measurement Tasks to perform and the > details of the Report to send. The MA Configuration is sent by a > Controller to a Measurement Agent. >=20 > If we wanted to just call this Configuration, we could then add the sentence: > Also simply referred to as "Configuration" where the context is clear. MA Configuration seems too broad to me given the current definition of Instruction: Instruction: The description of Measurement Tasks to perform and the details of the Report to send. The Instruction is sent by a Controller to a Measurement Agent. In other words, Instruction, as currently defined, is the subset of the MA Configuration pertaining to Measurement Tasks and the Reports. An unwieldy long term like 'Measurement Task and Report Configuration' would be more precise but not very practical. So yes, Instruction may not be ideal but so far I have not seen a good counter proposal. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Tue Sep 17 08:42:54 2013 Return-Path: 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 14B4C11E82A5 for ; Tue, 17 Sep 2013 08:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.948 X-Spam-Level: X-Spam-Status: No, score=-6.948 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 r2dmSE-RxqFs for ; Tue, 17 Sep 2013 08:42:47 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id F39E411E8110 for ; Tue, 17 Sep 2013 08:42:46 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 77878325.2aaad9e22940.412123.00-590.1132738.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 17 Sep 2013 15:42:47 +0000 (UTC) X-MXL-Hash: 523878771714572a-03be59463ace7f2818491c0e41c68b7daa1d9776 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 16878325.0.411822.00-468.1131881.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 17 Sep 2013 15:42:33 +0000 (UTC) X-MXL-Hash: 523878692589230c-3c93bfc763d27dd2f835236ee84022d87e3205ae Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8HFgPWt000607; Tue, 17 Sep 2013 11:42:25 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8HFgGib000436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 11:42:20 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (GAALPA1MSGHUB9A.itservices.sbc.com [130.8.36.87]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 17 Sep 2013 15:41:58 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.03.0158.001; Tue, 17 Sep 2013 11:41:58 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAC2hQkA== Date: Tue, 17 Sep 2013 15:41:57 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130370ABE@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.183.97] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130370ABEGAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=O8iOSmBW c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=LMeTTcwMbu4A:10 a=l4EBnxoveaQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Lb5Mp4LI0] X-AnalysisOut: [xsA:10 a=__vxbrYH6oM4TU4KsXMA:9 a=CjuIK1q_8ugA:10 a=yMhMjl] X-AnalysisOut: [ubAAAA:8 a=SSmOFEACAAAA:8 a=OUuyQhT5_p7M6bTLJxIA:9 a=gKO2H] X-AnalysisOut: [q4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-] X-AnalysisOut: [hUA:10 a=7XcwVcyyrwCBzE2h:21] Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:42:54 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130370ABEGAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. As it relates to a 'protocol model' for the framework, I'd want to be= careful here. RFC 4101 is really about modelling of a brand new protocol t= hat is going to be defined, or about providing a description of a particula= r protocol. In the context of LMAP, I thought we wanted to select existing = protocols, and not design new ones. Therefore, it's not modelling from a pr= otocol design perspective that we need to do, but identifying selection cri= teria for a protocol. This is a subtle distinction. What we create should = not attempt to describe "The LMAP Control Protocol" or "The LMAP Collector = Protocol" (because hopefully there will not exist a protocol solely dedicat= ed to these uses), but rather the criteria that a protocol would need to me= et in order to be used for one of these purposes. It's possible that multiple existing protocols will be able to meet the spe= cified criteria. I recognize that it's a goal of this WG to then select one= (for each purpose) and crown it as "The Protocol for IETF LMAP Control" or= "The Protocol for IETF LMAP Data Collection". But it should also be recogn= ized that the criteria alone may be useful, to entities who want to use a d= ifferent protocol for the same purpose. I believe that the criteria should = be written with that potential use in mind. At a high level, I agree conceptually with RFC 4101 type of modelling. My r= eal hope is that we not try to get into the level of detail that would be n= eeded to model a brand new protocol, but limit it to the level of detail ne= eded to select an existing protocol. Barbara --_000_2D09D61DDFA73D4C884805CC7865E61130370ABEGAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

thinking about = your process question – we’re now trying to write a ‘prot= ocol model’ for the framework doc (rfc4101) – so the protocol w= ill be described at this level.

&n= bsp;

<bhs> As it relates to a = ‘protocol model’ for the framework, I’d want to be carefu= l here. RFC 4101 is really about modelling of a brand new protocol that is = going to be defined, or about providing a description of a particular protocol. In the context of LMAP, I thought we wanted to select existing p= rotocols, and not design new ones. Therefore, it’s not modelling from= a protocol design perspective that we need to do, but identifying selectio= n criteria for a protocol.  This is a subtle distinction. What we create should not attempt to describe “T= he LMAP Control Protocol” or “The LMAP Collector Protocol”= ; (because hopefully there will not exist a protocol solely dedicated to th= ese uses), but rather the criteria that a protocol would need to meet in order to be used for one of these purposes.

 

It’s possible that multip= le existing protocols will be able to meet the specified criteria. I recogn= ize that it’s a goal of this WG to then select one (for each purpose)= and crown it as “The Protocol for IETF LMAP Control” or “The Protocol for IETF LMAP Data Collection”. But it should= also be recognized that the criteria alone may be useful, to entities who = want to use a different protocol for the same purpose. I believe that the c= riteria should be written with that potential use in mind.

 

At a high level, I agree concep= tually with RFC 4101 type of modelling. My real hope is that we not try to = get into the level of detail that would be needed to model a brand new prot= ocol, but limit it to the level of detail needed to select an existing protocol.

Barbara

--_000_2D09D61DDFA73D4C884805CC7865E61130370ABEGAALPA1MSGUSR9L_-- From acmorton@att.com Tue Sep 17 08:53:18 2013 Return-Path: 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 91BC111E8495 for ; Tue, 17 Sep 2013 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.723 X-Spam-Level: X-Spam-Status: No, score=-106.723 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Mq35VnbtMInY for ; Tue, 17 Sep 2013 08:53:12 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id EEA2C11E8493 for ; Tue, 17 Sep 2013 08:53:11 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 11EEC120A37; Tue, 17 Sep 2013 11:53:09 -0400 (EDT) Received: from njfpsrvexg9.research.att.com (unknown [135.207.255.240]) by mail-azure.research.att.com (Postfix) with ESMTP id AE2C3E200B; Tue, 17 Sep 2013 11:53:10 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg9.research.att.com ([fe80::e596:b2e3:df5e:6b93%15]) with mapi; Tue, 17 Sep 2013 11:53:10 -0400 From: "MORTON, ALFRED C (AL)" To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" Date: Tue, 17 Sep 2013 11:53:09 -0400 Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAC2hQkAABG0OA Message-ID: <2845723087023D4CB5114223779FA9C8AAC21A03@njfpsrvexg8.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370ABE@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130370ABE@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8AAC21A03njfpsrvexg8rese_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:53:18 -0000 --_000_2845723087023D4CB5114223779FA9C8AAC21A03njfpsrvexg8rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ... At a high level, I agree conceptually with RFC 4101 type of modelling. My r= eal hope is that we not try to get into the level of detail that would be needed to model a brand new protocol, but= limit it to the level of detail needed to select an existing protocol. Barbara Yes. I think what we intend, or what we had last night at least, are very high-level models for various LMAP interactions. Almost any protocol could fill the need, so your point is well-taken. Don't go too far at this stage... Al From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STA= RK, BARBARA H Sent: Tuesday, September 17, 2013 11:42 AM To: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. As it relates to a 'protocol model' for the framework, I'd want to be= careful here. RFC 4101 is really about modelling of a brand new protocol t= hat is going to be defined, or about providing a description of a particula= r protocol. In the context of LMAP, I thought we wanted to select existing = protocols, and not design new ones. Therefore, it's not modelling from a pr= otocol design perspective that we need to do, but identifying selection cri= teria for a protocol. This is a subtle distinction. What we create should = not attempt to describe "The LMAP Control Protocol" or "The LMAP Collector = Protocol" (because hopefully there will not exist a protocol solely dedicat= ed to these uses), but rather the criteria that a protocol would need to me= et in order to be used for one of these purposes. It's possible that multiple existing protocols will be able to meet the spe= cified criteria. I recognize that it's a goal of this WG to then select one= (for each purpose) and crown it as "The Protocol for IETF LMAP Control" or= "The Protocol for IETF LMAP Data Collection". But it should also be recogn= ized that the criteria alone may be useful, to entities who want to use a d= ifferent protocol for the same purpose. I believe that the criteria should = be written with that potential use in mind. At a high level, I agree conceptually with RFC 4101 type of modelling. My r= eal hope is that we not try to get into the level of detail that would be n= eeded to model a brand new protocol, but limit it to the level of detail ne= eded to select an existing protocol. Barbara --_000_2845723087023D4CB5114223779FA9C8AAC21A03njfpsrvexg8rese_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

…

At a high level, I agree= conceptually with RFC 4101 type of modelling. My real hope is that we not = try to get into

the level of detail that would be needed to mo= del a brand new protocol, but limit it to the level of detail needed

to select an existing protocol.

Barbara

 

Yes. I think what we intend= , or what we had last night at least,

are very hi= gh-level models for various LMAP interactions.

Al= most any protocol could fill the need, so your point is <= /p>

well-taken.  Don't go too far at this stage...

 

Al

 

From:= lma= p-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STARK= , BARBARA H
Sent: Tuesday, September 17, 2013 11:42 AM
To:<= /b> philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] LMAP= Framework issue #3 (take 2) Interactions between MA and Controller

 

thinking about your process question – w= e’re now trying to write a ‘protocol model’ for the frame= work doc (rfc4101) – so the protocol will be described at this level.=

 

<bhs> As it relates to a ‘protocol model’ for the fr= amework, I’d want to be careful here. RFC 4101 is really about modell= ing of a brand new protocol that is going to be defined, or about providing= a description of a particular protocol. In the context of LMAP, I thought = we wanted to select existing protocols, and not design new ones. Therefore,= it’s not modelling from a protocol design perspective that we need t= o do, but identifying selection criteria for a protocol.  This is a su= btle distinction. What we create should not attempt to describe “The = LMAP Control Protocol” or “The LMAP Collector Protocol” (= because hopefully there will not exist a protocol solely dedicated to these= uses), but rather the criteria that a protocol would need to meet in order= to be used for one of these purposes.

 

<= span lang=3DEN-GB>It’s possible that multiple existing protocols will= be able to meet the specified criteria. I recognize that it’s a goal= of this WG to then select one (for each purpose) and crown it as “Th= e Protocol for IETF LMAP Control” or “The Protocol for IETF LMA= P Data Collection”. But it should also be recognized that the criteri= a alone may be useful, to entities who want to use a different protocol for= the same purpose. I believe that the criteria should be written with that = potential use in mind.

 

At a high level, I agree conceptually with RFC 4101 type of modelling. My= real hope is that we not try to get into the level of detail that would be= needed to model a brand new protocol, but limit it to the level of detail = needed to select an existing protocol.

Barbara

= --_000_2845723087023D4CB5114223779FA9C8AAC21A03njfpsrvexg8rese_-- From trevor.burbridge@bt.com Tue Sep 17 09:21:41 2013 Return-Path: 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 D38A411E84C2 for ; Tue, 17 Sep 2013 09:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.769 X-Spam-Level: X-Spam-Status: No, score=-2.769 tagged_above=-999 required=5 tests=[AWL=1.629, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] 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 yzJwALY2r0gD for ; Tue, 17 Sep 2013 09:21:33 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 37A1411E84AD for ; Tue, 17 Sep 2013 09:21:31 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 17 Sep 2013 17:21:29 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 17 Sep 2013 17:21:29 +0100 From: To: , , , Date: Tue, 17 Sep 2013 17:21:28 +0100 Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAAD0AhwAAAihGAAAgLhkA== Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72C171A6B6BEMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:21:42 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72C171A6B6BEMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To give a bit of reasoning while I selected "Instruction" to start with... - There is also a configuration command/information about the genera= l settings of the MA (such as MA ID, Group ID etc.). So configuration is ta= ken (unless we change that as well) - It is specifically about getting the MA to do something - either c= onduct measurements and produce reports. The stuff in "Configuration" doesn= 't result in anything actually being done. I think "instruction" is pretty descriptive and appropriate, but then I'm o= bviously biased. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Rom= ascanu, Dan (Dan) Sent: 17 September 2013 16:22 To: Eardley,PL,Philip,TUB8 R; bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Neither do I (feel strongly either way). However I believe that Configurati= on risks to be also mis-leading, and not consistent with other usages of th= e term in the industry (or on the MA or the MA host). What about "Procedure= " or "MA Procedure"? Dan (speaking as contributor) From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Tuesday, September 17, 2013 5:16 PM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller What do other people think? I don't have a strong feeling either way. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 September 2013 14:51 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller I see that your use of "Instruction" is consistent with its proposed LMAP t= erminology definition. And I have no problem with there being a term with t= hat definition. It would appear that my problem is with the choice of "Instruction" as the = word to apply this definition to. The proposed terminology definition uses "Instruction" in a manner that I d= on't consider completely consistent with the way I generally use the word. In computing, "Instruction" is a very basic, low-level message. Such a mess= age tells the computer to do something very specific. There are many, many = instructions in a computer's "instruction set". I've also seen this term used with other inter-device communication. As wit= h computing "instructions", this sort of communication has many different t= ypes of messages, such that each desired action has its own "instruction". In the absence of actually reading the lmap terminology definition, and for= cing myself to accept that lmap is using this word in what I consider an in= dustry-inconsistent way, I would misinterpret the use of this word (and did= in fact misinterpret it). For me, "instruction" in the context of some of the xml-based WAN configura= tion protocols we're looking at, would map to an RPC (Remote Procedure Call= ), if there were not a terminology definition telling me that I should not = misinterpret the word in this manner. I believe it is problematic to select a term that is so commonly used in th= e industry, and provide it with a definition that is not consistent with th= at common usage. I believe the term could easily be replaced by: MA Configuration: The description of Measurement Tasks to perform and th= e details of the Report to send. The MA Configuration is sent by a Controller to a Measurement Agent. If we wanted to just call this Configuration, we could then add the sentenc= e: Also simply referred to as "Configuration" where the context is clear. Barbara From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Tuesday, September 17, 2013 5:59 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Thanks Barbara. thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. Not sure I fully understood your point about Instruction. I was trying to use it as defined in the terminology <> The Instruction would be a message with - one of more Measurement Tasks - one of more Schedules - one or more Report Channels I guess the first msg from Controller to MA includes all of these. Subseque= nt msgs might only update one of them, for instance the Schedule might get = updated rather more often than the other two items. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 12 September 2013 19:34 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_ED51D9282D1D3942B9438CA8F3372EB72C171A6B6BEMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To give a bit of reasoning while I selected “Instructio= n” to start with…

 

-     &nbs= p;  There= is also a configuration command/information about the general settings of = the MA (such as MA ID, Group ID etc.). So configuration is taken (unless we= change that as well)

-        It is specificall= y about getting the MA to do something – either conduct measurements = and produce reports. The stuff in “Configuration” doesn’t= result in anything actually being done.

 

I think “instruction”= ; is pretty descriptive and appropriate, but then I’m obviously biase= d.

=  

Trevor.

 

Trev= or Burbridge
Network Infrastructure & Innovation | BT Innovate &= Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT information, which= may be privileged or confidential. It's meant only for the individual(s) o= r entity named above. If you're not the intended recipient, note that discl= osing, copying, distributing or using this information is prohibited. If yo= u've received this email in error, please let me know immediately on the em= ail address above. Thank you.
We monitor our email system, and may recor= d your emails.
British= Telecommunications plc
Registered office: 81 Newgate Street London EC1A= 7AJ
Registered in England no: 1800000

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces= @ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: 17 Sept= ember 2013 16:22
To: Eardley,PL,Philip,TUB8 R; bs7652@att.com; lm= ap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) = Interactions between MA and Controller

 

Neither do I (feel strongly either way). Howeve= r I believe that Configuration risks to be also mis-leading, and not consis= tent with other usages of the term in the industry (or on the MA or the MA = host). What about “Procedure” or “MA Procedure”?

 

Dan

(speaking as contributor)

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Tuesday, S= eptember 17, 2013 5:16 PM
To: b= s7652@att.com; lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions betw= een MA and Controller

 

What= do other people think?

I don&#= 8217;t have a strong feeling either way.

 

From: STARK, BARBARA H [mailto:bs7652@att.com]
Sent: 17 September 2013 = 14:51
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: [lmap] LMAP Framework issue #3= (take 2) Interactions between MA and Controller

 

I see that your use of “Instruc= tion” is consistent with its proposed LMAP terminology definition. An= d I have no problem with there being a term with that definition.

 

It would appear that my problem is with the choice of &#= 8220;Instruction” as the word to apply this definition to.=

=  

The proposed terminology definition uses “Instruct= ion” in a manner that I don’t consider completely consistent wi= th the way I generally use the word.

In computing, “Instruc= tion” is a very basic, low-level message. Such a message tells the co= mputer to do something very specific. There are many, many instructions in = a computer’s “instruction set”.

I’ve also= seen this term used with other inter-device communication. As with computi= ng “instructions”, this sort of communication has many differen= t types of messages, such that each desired action has its own “instr= uction”.

In the absence of actually reading the lmap termin= ology definition, and forcing myself to accept that lmap is using this word= in what I consider an industry-inconsistent way, I would misinterpret the = use of this word (and did in fact misinterpret it).

For me, ̶= 0;instruction” in the context of some of the xml-based WAN configurat= ion protocols we’re looking at, would map to an RPC (Remote Procedure= Call), if there were not a terminology definition telling me that I should= not misinterpret the word in this manner.

I believe it is pro= blematic to select a term that is so commonly used in the industry, and pro= vide it with a definition that is not consistent with that common usage.

 

I believe the term could easily be replaced by:

   MA Configuration: The des= cription of Measurement Tasks to perform and the

   details of the Report to send.  The MA Confi= guration is sent by a

   = Controller to a Measurement Agent.

=  

If we wanted to just call this Configuration, we could t= hen add the sentence:

Also simply r= eferred to as “Configuration” where the context is clear.<= /o:p>

 

Barbara

 

 =

From: philip.eardley@bt.com = [mailto:philip.eardley@bt.com]=
Sent: Tuesday, September 17, 2013 5:59 AM
To: STARK, = BARBARA H; lmap@ietf.org
Subject= : RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA a= nd Controller

 

Thanks Barba= ra.

thinking about your process= question – we’re now trying to write a ‘protocol model&#= 8217; for the framework doc (rfc4101) – so the protocol will be descr= ibed at this level.

&nbs= p;

Not sure I fully understood your = point about Instruction.

I was = trying to use it as defined in the terminology

<<Instruction: The description of Measurement Tasks to perform and the<=
/o:p>

<= span lang=3DEN style=3D'font-size:10.0pt;font-family:"Courier New"'> &= nbsp; details of the Report to send.  The Instruction is sent by a

<= span lang=3DEN style=3D'font-size:10.0pt;font-family:"Courier New"'> &= nbsp; Controller to a Measurement Agent.

>> 

 

The Instruction would be a message with

-       = ; one of more Measurement Tasks<= o:p>

-  = ;      one of more Schedules

-        one or more Report Channels

I guess the first msg from Controller to MA = includes all of these. Subsequent msgs might only update one of them, for i= nstance the Schedule might get updated rather more often than the other two= items.

 <= /o:p>

      =             &nb= sp;            =             &nb= sp;            =             

From:= STARK, BARBARA H [mailto= :bs7652@att.com]
Sent: 12 September 2013 19:34
To:= Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interacti= ons between MA and Controller

 

First a process question:

How detailed is thi= s Framework document supposed to be? Is it intended to include the full lis= t of criteria for a Control Protocol, or will these criteria be documented = separately? If the first, then I would prefer for the criteria to be more p= recisely described, and easy to identify as Control Protocol criteria/requi= rements. If the latter, then I would prefer for the Framework to use more d= escriptive language as to what is expected of the Control Protocol, rather = than trying to give names to all of the various expected functionality (e.g= ., Instruction, registration). More detailed comments below.

Barb= ara

 

From: lmap-bounces@ietf.org [ma= ilto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Thursday, Septe= mber 12, 2013 11:45 AM
To: lmap@= ietf.org
Subject: [lmap] LMAP Framework issue #3 (take 2) Int= eractions between MA and Controller

 

Thanks for the nice discussion, I’ve tried to re-write to reflect= where I think we’ve got to. I also changed the title to:<= /span>

 

Int= eractions between MA and Controller

A= s part of a bootstrap process the MA gets sufficient information to contact= a Controller. Defining a bootstrap mechanism is out of scope of the LMAP W= G.

 

The basic interaction between a Controller and MA is that the Co= ntroller sends an Instruction to the MA, detailing what Measurement Tasks t= o do, when to do them, and how to report the Measurement Results. In genera= l we expect that the measurement system understands what Measurement Method= s the MA can do and therefore the Controller can simply instruct the MA; th= ere is no need for a negotiation protocol (which would add complexity to th= e MA, Controller and Control Protocol). However, it is possible that the MA= is in fact not capable of performing the requested Measurement Method, and= so the Control Protocol must allow the MA to reply with a suitable error c= ode.

 

<bhs> The use of the word “Instruction” here makes= me uncomfortable, because it implies (at least to me) a manner of communic= ation that is not quite consistent with the way most WAN-based massive-numb= er-of-controlled-devices control protocols work today. “Instruction&#= 8221; suggests a manner of communication where the desired action is a part= of the basic message. Having separate message syntax (actions) for everyth= ing the Controller wants the MA to do would greatly increase the number of = messages that need to go back and forth between MA and controller. This sor= t of interaction is common in protocols intended to work on LAN segments. I= t’s a very bad idea for protocols intended to work over the WAN that = are intended to scale to large numbers of devices, and be highly extensible= . I would prefer if we did not attempt to give this function of the Control= ler to MA interaction a proper name (denoted by a capital first letter). I = would also prefer if we described it as “the Controller configures th= e MA”, using the word “configure” instead of “instr= uct”.

 

I don’t think we’ve defined “negotiation pr= otocol”. Probably because we don’t need it. I would prefer if w= e got rid of that (negotiation protocol) sentence and just used the last se= ntence as a positive statement about what we do expect from the Control Pro= tocol. For example: The Control Protocol must support robust error reportin= g by the MA, to provide the Controller with sufficiently-detailed reasons f= or any failures in configuration.

 

Is “measurement system” defi= ned? I’m a bit unclear on what this is.

 

Resulting recommended text:<= o:p>

The basic interaction b= etween a Controller and MA is that the Controller configures the MA, detail= ing what Measurement Tasks to do, when to do them, and how to report the Me= asurement Results. In general we expect that the Controller knows what Meas= urement Methods the MA supports, such that the Controller can correctly con= figure the MA. However, the Control Protocol must support robust error repo= rting by the MA, to provide the Controller with sufficiently-detailed reaso= ns for any failures in configuration.

The MA can send to the Contr= oller the list of Measurement Methods that it is capable of. This could be = useful:

[1] as part of the MA registe= ring with the Controller. Note that in some scenarios it is not needed, as = the Controller will know the information by other means, for example as par= t of the bootstrapping process (using Tr-069 say) or because the MA is stat= ically configured.

[2] so the MA can = re-register, for example if it becomes capable of a new Measurement Method.=

** Comment: suggest we keep it simp= le and just send the complete list, rather than a delta. The message should= be short, since Methods are referred to via a registry.<= /p>

[3] when requested by the Controller, which could be us= eful if ‘something goes wrong’ and the Controller forgets what = the MA can do.

 

<bhs> The word “register” also makes m= e uncomfortable, though not as much as “Instruct”. This implies= to me some very specific functionality than I don’t consider complet= ely necessary. But maybe if “registration” were defined I would= feel better about it. The “**Comment” suggestion is too specif= ic for the Framework, IMO. But if Framework has detailed Control Protocol c= riteria, then I would reword the statement as “The Control Protocol m= ust allow the Controller to request the MA supply the MA’s complete l= ist of supported Measurement Methods, in a concise format.”  I w= ould prefer if the above statements were reworded as:

=

The MA can send to the Controller the list o= f Measurement Methods that it is capable of. This could be useful:

[1] when the MA first communica= tes with a Controller.

[2] when the MA becomes capable of a new Measurement Method.

[3] when requested by the Controlle= r (e.g., if the Controller forgets what the MA can do or otherwise wants to= resynchronize what it knows about the MA).

 

Note that the advert = contains the list of Measurement Methods that the MA can perform. It is not= intended to indicate dynamic capabilities like the MA’s currently un= used CPU, memory or battery life.

**= Comment: I’m not sure whether we reached consensus on this point.

 

<bhs> I would have no objection t= o including such capabilities as optional elements of the information model= . In fact, I think it would be a good idea. But I don’t think this ne= eds to be mentioned in the Framework.

 

It is possible that later, wh= en a MA is implementing the Instruction, it does not perform a particular M= easurement Task for some reason, such as: the Measurement Peer is busy, or = there is cross-traffic, … The MA doesn’t inform the Controller,= instead it is reported to the Collector as part of the Measurement Report.= The Collector may in turn tell the measurement system or even the Controll= er, but this is out of scope of LMAP.

** Comment: are there any conditions when it’s critical for the Cont= roller to be informed?

 

<bhs> Ditto my previous objection to “I= nstruction”. I believe the information model needs to include status = parameters that would allow the Controller to request this info, at some le= vel. This can be optional to support for MA and Controller. I recommend rew= ording to:

It is possib= le that an MA is unable to carry out a configured Measurement Task. Possibl= e reasons include the Measurement Peer being busy, presence of cross-traffi= c, … The MA will report this information to the Collector as part of = the Measurement Report. The Collector may in turn tell other systems (inclu= ding, possibly, the Controller), but this is out of scope of LMAP. The MA m= ay also be able to inform the Controller directly of such occurrences.=

&n= bsp;

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 05 Septem= ber 2013 11:13
To: lmap@ietf.org=
Subject: [lmap] LMAP Framework issue #3 No negotiation betwe= en MA and Controller

=  

Another issue:

<= p class=3DMsoNormal>There is no negotiation between the MA and Controller - the= Controller simply sends the Instruction to the MA, with the details of the= Measurement Tasks to perform.

<= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>In ge= neral we expect that the measurement system understands the capabilities of= its MAs (probably there are only one or a few classes of MA), so negotiati= on about the MA’s capabilities would have little benefit. It would al= so add complexity to the MA, Controller and Control Protocol.

 

= It i= s possible that the MA can’t perform the requested Measurement Task. = So the Control Protocol needs to allow the MA to reply with an error code. = It has also been suggested that the Controller should be able to ask the MA= to send a list of all the Measurement Methods that it is capable of, in ca= se ‘something goes wrong’ and the Controller forgets what the M= A can do. Comment: this idea hasn’t had much discussion yet, but appe= ars in the Information Model i-d

=  

Thoughts?

Thanks

phil=

= --_000_ED51D9282D1D3942B9438CA8F3372EB72C171A6B6BEMV64UKRDdoma_-- From acmorton@att.com Tue Sep 17 09:44:11 2013 Return-Path: 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 4B29B11E82AA for ; Tue, 17 Sep 2013 09:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.109 X-Spam-Level: X-Spam-Status: No, score=-107.109 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 lzCd5LF277C3 for ; Tue, 17 Sep 2013 09:43:52 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2564D11E80EA for ; Tue, 17 Sep 2013 09:43:50 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 29CF6120A82; Tue, 17 Sep 2013 12:43:48 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 69297E0182; Tue, 17 Sep 2013 12:43:20 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Tue, 17 Sep 2013 12:43:49 -0400 From: "MORTON, ALFRED C (AL)" To: "trevor.burbridge@bt.com" , "dromasca@avaya.com" , "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" Date: Tue, 17 Sep 2013 12:43:49 -0400 Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAAD0AhwAAAihGAAAgLhkAAAruFQ Message-ID: <2845723087023D4CB5114223779FA9C8AAC21A30@njfpsrvexg8.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8AAC21A30njfpsrvexg8rese_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:44:12 -0000 --_000_2845723087023D4CB5114223779FA9C8AAC21A30njfpsrvexg8rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ... I think "instruction" is pretty descriptive and appropriate, but then I'm o= bviously biased. Trevor. +1, and if there's still confusion, add the adjective "Measurement". I've been using this term frequently in writing assignments, and it hasn't tripped me up yet (which reminds me, it's the term we used in the lmap charter, too). Al From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of tre= vor.burbridge@bt.com Sent: Tuesday, September 17, 2013 12:21 PM To: dromasca@avaya.com; philip.eardley@bt.com; STARK, BARBARA H; lmap@ietf.= org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller To give a bit of reasoning while I selected "Instruction" to start with... - There is also a configuration command/information about the gene= ral settings of the MA (such as MA ID, Group ID etc.). So configuration is = taken (unless we change that as well) - It is specifically about getting the MA to do something - either= conduct measurements and produce reports. The stuff in "Configuration" doe= sn't result in anything actually being done. I think "instruction" is pretty descriptive and appropriate, but then I'm o= bviously biased. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Rom= ascanu, Dan (Dan) Sent: 17 September 2013 16:22 To: Eardley,PL,Philip,TUB8 R; bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Neither do I (feel strongly either way). However I believe that Configurati= on risks to be also mis-leading, and not consistent with other usages of th= e term in the industry (or on the MA or the MA host). What about "Procedure= " or "MA Procedure"? Dan (speaking as contributor) From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Tuesday, September 17, 2013 5:16 PM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller What do other people think? I don't have a strong feeling either way. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 September 2013 14:51 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller I see that your use of "Instruction" is consistent with its proposed LMAP t= erminology definition. And I have no problem with there being a term with t= hat definition. It would appear that my problem is with the choice of "Instruction" as the = word to apply this definition to. The proposed terminology definition uses "Instruction" in a manner that I d= on't consider completely consistent with the way I generally use the word. In computing, "Instruction" is a very basic, low-level message. Such a mess= age tells the computer to do something very specific. There are many, many = instructions in a computer's "instruction set". I've also seen this term used with other inter-device communication. As wit= h computing "instructions", this sort of communication has many different t= ypes of messages, such that each desired action has its own "instruction". In the absence of actually reading the lmap terminology definition, and for= cing myself to accept that lmap is using this word in what I consider an in= dustry-inconsistent way, I would misinterpret the use of this word (and did= in fact misinterpret it). For me, "instruction" in the context of some of the xml-based WAN configura= tion protocols we're looking at, would map to an RPC (Remote Procedure Call= ), if there were not a terminology definition telling me that I should not = misinterpret the word in this manner. I believe it is problematic to select a term that is so commonly used in th= e industry, and provide it with a definition that is not consistent with th= at common usage. I believe the term could easily be replaced by: MA Configuration: The description of Measurement Tasks to perform and th= e details of the Report to send. The MA Configuration is sent by a Controller to a Measurement Agent. If we wanted to just call this Configuration, we could then add the sentenc= e: Also simply referred to as "Configuration" where the context is clear. Barbara From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Tuesday, September 17, 2013 5:59 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Thanks Barbara. thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. Not sure I fully understood your point about Instruction. I was trying to use it as defined in the terminology <> The Instruction would be a message with - one of more Measurement Tasks - one of more Schedules - one or more Report Channels I guess the first msg from Controller to MA includes all of these. Subseque= nt msgs might only update one of them, for instance the Schedule might get = updated rather more often than the other two items. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 12 September 2013 19:34 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_2845723087023D4CB5114223779FA9C8AAC21A30njfpsrvexg8rese_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

…

I think “instruction” is pretty descrip= tive and appropriate, but then I’m obviously biased.

&= nbsp;

Trevor.

 

+1, and if there's still confusion, add the a= djective "Measurement".

 

I've been using this term frequently in writing assignmen= ts,

and it hasn't tripped me up yet (which remin= ds me,

it's the term we used in the lmap charter= , too).

 

Al<= /o:p>

 

 

From: lmap-bounces@ietf.org = [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.com<= br>Sent: Tuesday, September 17, 2013 12:21 PM
To: dromasca= @avaya.com; philip.eardley@bt.com; STARK, BARBARA H; lmap@ietf.org
Su= bject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between= MA and Controller

 

To give a bit of reasoning while I selected “Instruction̶= 1; to start with…

 

-  &nb= sp;       There is also a configuration comman= d/information about the general settings of the MA (such as MA ID, Group ID= etc.). So configuration is taken (unless we change that as well)

-          It is speci= fically about getting the MA to do something – either conduct measure= ments and produce reports. The stuff in “Configuration” doesn&#= 8217;t result in anything actually being done.

 <= /span>

I= think “instruction” is pretty descriptive and appropriate, but= then I’m obviously biased.

 

Trevor.

 

Trevor Burbridge
Network Infrastructure & Innovation | BT Innova= te & Design
Tel: 01473 645115
Fax: 01473 640929

This em= ail contains BT information, which may be privileged or confidential. It's = meant only for the individual(s) or entity named above. If you're not the i= ntended recipient, note that disclosing, copying, distributing or using thi= s information is prohibited. If you've received this email in error, please= let me know immediately on the email address above. Thank you.
We monit= or our email system, and may record your emails.
British Telecommunicati= ons plc
Registered office: 81 Newgate Street London EC1A 7AJ
Register= ed in England no: 1800000=

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] O= n Behalf Of Romascanu, Dan (Dan)
Sent: 17 September 2013 16:2= 2
To: Eardley,PL,Philip,TUB8 R; bs7652@att.com; lmap@ietf.org
= Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

Neither do I (feel strongly either way). However = I believe that Configuration risks to be also mis-leading, and not consiste= nt with other usages of the term in the industry (or on the MA or the MA ho= st). What about “Procedure” or “MA Procedure”?=

&n= bsp;

Dan=

(s= peaking as contributor)

 

 

=

From: lmap-boun= ces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Tuesday, September 17, 2013 5= :16 PM
To: bs7652@att.com; = lmap@ietf.org
Subject: Re: [= lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controll= er

 <= /p>

What do other people think?

I don’t have a stron= g feeling either way.

 

= From:= STARK, BARBARA H [mailto:bs7652@att.c= om]
Sent: 17 September 2013 14:51
To: Eardley,PL,P= hilip,TUB8 R; lmap@ietf.org
Subj= ect: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller

 

I see that your use of “Instruction” is cons= istent with its proposed LMAP terminology definition. And I have no problem= with there being a term with that definition.

 

It would appear that my pr= oblem is with the choice of “Instruction” as the word to apply = this definition to.

 

The proposed terminology definition uses “Inst= ruction” in a manner that I don’t consider completely consisten= t with the way I generally use the word.

In computing, “Instruction̶= 1; is a very basic, low-level message. Such a message tells the computer to= do something very specific. There are many, many instructions in a compute= r’s “instruction set”.

I’ve also seen this term used w= ith other inter-device communication. As with computing “instructions= ”, this sort of communication has many different types of messages, s= uch that each desired action has its own “instruction”.

In the abs= ence of actually reading the lmap terminology definition, and forcing mysel= f to accept that lmap is using this word in what I consider an industry-inc= onsistent way, I would misinterpret the use of this word (and did in fact m= isinterpret it).

For me, “instruction” in the context of some of t= he xml-based WAN configuration protocols we’re looking at, would map = to an RPC (Remote Procedure Call), if there were not a terminology definiti= on telling me that I should not misinterpret the word in this manner. =

I belie= ve it is problematic to select a term that is so commonly used in the indus= try, and provide it with a definition that is not consistent with that comm= on usage.

 

I believe the term could easily be replaced by:

   MA Configuration: The description of Measurement Tas= ks to perform and the

   details of the= Report to send.  The MA Configuration is sent by a<= /p>

   Controller to a Measurement Agent. <= /p>

 

If we wanted to just call this Configuration, we could then add= the sentence:

Also simply referred to as “= Configuration” where the context is clear.

 

<= p class=3DMsoNormal>Barbara

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Tuesda= y, September 17, 2013 5:59 AM
To: STARK, BARBARA H; lmap@ietf.org
Subject: RE: [lmap] LMAP Fr= amework issue #3 (take 2) Interactions between MA and Controller=

 

Thanks Barbara.

thinking about your process question – we= ’re now trying to write a ‘protocol model’ for the framew= ork doc (rfc4101) – so the protocol will be described at this level. =

 =

Not sure I fully understood = your point about Instruction.

I was trying to use it as defined in the terminology= 

<<Instruction: The description of Measuremen=
t Tasks to perform and the

   details of the Report to send.  = The Instruction is sent by a

   Controller to a Measurement Agent.

>> 

 

<= p class=3DMsoNormal>The Instruction would be a message with

-  &n= bsp;    one of mo= re Measurement Tasks

-       one of more Schedules

-       = one or more Report Channels<= /p>

I guess the first msg from Controller t= o MA includes all of these. Subsequent msgs might only update one of them, = for instance the Schedule might get updated rather more often than the othe= r two items.

&n= bsp;

   =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

= From: STARK, BARBARA H [mailto:bs7652@= att.com]
Sent: 12 September 2013 19:34
To: Eardley= ,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions betw= een MA and Controller

 

First a process question:

How detailed is this Framewo= rk document supposed to be? Is it intended to include the full list of crit= eria for a Control Protocol, or will these criteria be documented separatel= y? If the first, then I would prefer for the criteria to be more precisely = described, and easy to identify as Control Protocol criteria/requirements. = If the latter, then I would prefer for the Framework to use more descriptiv= e language as to what is expected of the Control Protocol, rather than tryi= ng to give names to all of the various expected functionality (e.g., Instru= ction, registration). More detailed comments below.

Barbara<= /p>

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent:= Thursday, September 12, 2013 11:45 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue= #3 (take 2) Interactions between MA and Controller

 

Thanks for the nice discussion, I’ve tried to re-write to refl= ect where I think we’ve got to. I also changed the title to:

 

Interactions between MA and Controller=

As part of a bootstrap process the= MA gets sufficient information to contact a Controller. Defining a bootstr= ap mechanism is out of scope of the LMAP WG.

 

The basic interaction between a Controller and MA is that the Controll= er sends an Instruction to the MA, detailing what Measurement Tasks to do, = when to do them, and how to report the Measurement Results. In general we e= xpect that the measurement system understands what Measurement Methods the = MA can do and therefore the Controller can simply instruct the MA; there is= no need for a negotiation protocol (which would add complexity to the MA, = Controller and Control Protocol). However, it is possible that the MA is in= fact not capable of performing the requested Measurement Method, and so th= e Control Protocol must allow the MA to reply with a suitable error code. <= o:p>

 

<bhs> The use of the word “Instructi= on” here makes me uncomfortable, because it implies (at least to me) = a manner of communication that is not quite consistent with the way most WA= N-based massive-number-of-controlled-devices control protocols work today. = “Instruction” suggests a manner of communication where the desi= red action is a part of the basic message. Having separate message syntax (= actions) for everything the Controller wants the MA to do would greatly inc= rease the number of messages that need to go back and forth between MA and = controller. This sort of interaction is common in protocols intended to wor= k on LAN segments. It’s a very bad idea for protocols intended to wor= k over the WAN that are intended to scale to large numbers of devices, and = be highly extensible. I would prefer if we did not attempt to give this fun= ction of the Controller to MA interaction a proper name (denoted by a capit= al first letter). I would also prefer if we described it as “the Cont= roller configures the MA”, using the word “configure” ins= tead of “instruct”.

=  

I don’t t= hink we’ve defined “negotiation protocol”. Probably becau= se we don’t need it. I would prefer if we got rid of that (negotiatio= n protocol) sentence and just used the last sentence as a positive statemen= t about what we do expect from the Control Protocol. For example: The Contr= ol Protocol must support robust error reporting by the MA, to provide the C= ontroller with sufficiently-detailed reasons for any failures in configurat= ion.

 

Is “measurement system” define= d? I’m a bit unclear on what this is.

 

Re= sulting recommended text:

The basic interaction between a Controller and MA is that t= he Controller configures the MA, detailing what Measurement Tasks to do, wh= en to do them, and how to report the Measurement Results. In general we exp= ect that the Controller knows what Measurement Methods the MA supports, suc= h that the Controller can correctly configure the MA. However, the Control = Protocol must support robust error reporting by the MA, to provide the Cont= roller with sufficiently-detailed reasons for any failures in configuration= .

 

The MA can send to the Controller the = list of Measurement Methods that it is capable of. This could be useful:

[1] as part of the MA regi= stering with the Controller. Note that in some scenarios it is not needed, = as the Controller will know the information by other means, for example as = part of the bootstrapping process (using Tr-069 say) or because the MA is s= tatically configured.

[= 2] so the MA can re-register, for example if it becomes capable of a new Me= asurement Method.

** Co= mment: suggest we keep it simple and just send the complete list, rather th= an a delta. The message should be short, since Methods are referred to via = a registry.

[3] when req= uested by the Controller, which could be useful if ‘something goes wr= ong’ and the Controller forgets what the MA can do.

&= nbsp;

<bhs> The word “register” also makes me uncomf= ortable, though not as much as “Instruct”. This implies to me s= ome very specific functionality than I don’t consider completely nece= ssary. But maybe if “registration” were defined I would feel be= tter about it. The “**Comment” suggestion is too specific for t= he Framework, IMO. But if Framework has detailed Control Protocol criteria,= then I would reword the statement as “The Control Protocol must allo= w the Controller to request the MA supply the MA’s complete list of s= upported Measurement Methods, in a concise format.”  I would pre= fer if the above statements were reworded as:

The MA can send to the Controller the l= ist of Measurement Methods that it is capable of. This could be useful:

[1] when the = MA first communicates with a Controller.

[2] when the MA becomes capable of a new Me= asurement Method.

[3] when requested by the Controller (e.g., if the Controller forg= ets what the MA can do or otherwise wants to resynchronize what it knows ab= out the MA).

 =

Note that the advert contain= s the list of Measurement Methods that the MA can perform. It is not intend= ed to indicate dynamic capabilities like the MA’s currently unused CP= U, memory or battery life.

** Comment: I’m not sure whether we reached consensus on this poi= nt.

 =

<bhs= > I would have no objection to including such capabilities as optional e= lements of the information model. In fact, I think it would be a good idea.= But I don’t think this needs to be mentioned in the Framework.<= /o:p>

 

<= p class=3DMsoNormal>It is possible that later, when a MA is implem= enting the Instruction, it does not perform a particular Measurement Task f= or some reason, such as: the Measurement Peer is busy, or there is cross-tr= affic, … The MA doesn’t inform the Controller, instead it is re= ported to the Collector as part of the Measurement Report. The Collector ma= y in turn tell the measurement system or even the Controller, but this is o= ut of scope of LMAP.

*= * Comment: are there any conditions when it’s critical for the Contro= ller to be informed?

 

<bhs> Ditto my prev= ious objection to “Instruction”. I believe the information mode= l needs to include status parameters that would allow the Controller to req= uest this info, at some level. This can be optional to support for MA and C= ontroller. I recommend rewording to:

It is possible that an MA is unable to carry out= a configured Measurement Task. Possible reasons include the Measurement Pe= er being busy, presence of cross-traffic, … The MA will report this i= nformation to the Collector as part of the Measurement Report. The Collecto= r may in turn tell other systems (including, possibly, the Controller), but= this is out of scope of LMAP. The MA may also be able to inform the Contro= ller directly of such occurrences.

 

 

 

<= p class=3DMsoNormal>From: lmap-bounc= es@ietf.org [mailto:lmap-bounc= es@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 05 September 2013 11:13
= To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller<= o:p>

 

Another issue:=

There is no negotiation betw= een the MA and Controller - the Controller simply sends the Instruction to = the MA, with the details of the Measurement Tasks to perform.

In general we expect that the measur= ement system understands the capabilities of its MAs (probably there are on= ly one or a few classes of MA), so negotiation about the MA’s capabil= ities would have little benefit. It would also add complexity to the MA, Co= ntroller and Control Protocol.

<= span lang=3DEN-GB style=3D'font-size:12.0pt;font-family:"Times New Roman","= serif"'> 

It is pos= sible that the MA can’t perform the requested Measurement Task. So th= e Control Protocol needs to allow the MA to reply with an error code. It ha= s also been suggested that the Controller should be able to ask the MA to s= end a list of all the Measurement Methods that it is capable of, in case &#= 8216;something goes wrong’ and the Controller forgets what the MA can= do. Comment: this idea hasn’t had much discussion yet, but appears i= n the Information Model i-d

 

Thoughts?

Thanks

phil

= --_000_2845723087023D4CB5114223779FA9C8AAC21A30njfpsrvexg8rese_-- From Michael.K.Bugenhagen@centurylink.com Tue Sep 17 10:12:43 2013 Return-Path: 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 1118D11E8125 for ; Tue, 17 Sep 2013 10:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6] 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 7g2+7qvkQ56R for ; Tue, 17 Sep 2013 10:12:34 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC3611E812A for ; Tue, 17 Sep 2013 10:12:31 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r8HHCOtk000337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 12:12:25 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 7DE841E0068; Tue, 17 Sep 2013 12:12:19 -0500 (CDT) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 5591D1E0059; Tue, 17 Sep 2013 12:12:19 -0500 (CDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r8HHCIfL020677; Tue, 17 Sep 2013 12:12:18 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r8HHCIXa020662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Sep 2013 12:12:18 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.02.0318.001; Tue, 17 Sep 2013 12:12:17 -0500 From: "Bugenhagen, Michael K" To: "'trevor.burbridge@bt.com'" , "dromasca@avaya.com" , "philip.eardley@bt.com" , "bs7652@att.com" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAAD0AhwAAAihGAAAgLhkAAB2+XA Date: Tue, 17 Sep 2013 17:12:17 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C1F72podcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 17:12:43 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C1F72podcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm hoping the group assumes Interoperability as a significantly high prior= ity here. If we ever hope to have a DSL modem, or Cable modem, wireless phone, ...= . To be delivered with MA capabilities it really must have a standard comma= nd set or we'll end up with code variants that inhibit interop. So I'm leaning to a common command set - I don't care what you call it, but= it needs to be standard across the board. From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of tre= vor.burbridge@bt.com Sent: Tuesday, September 17, 2013 11:21 AM To: dromasca@avaya.com; philip.eardley@bt.com; bs7652@att.com; lmap@ietf.or= g Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller To give a bit of reasoning while I selected "Instruction" to start with... - There is also a configuration command/information about the gene= ral settings of the MA (such as MA ID, Group ID etc.). So configuration is = taken (unless we change that as well) - It is specifically about getting the MA to do something - either= conduct measurements and produce reports. The stuff in "Configuration" doe= sn't result in anything actually being done. I think "instruction" is pretty descriptive and appropriate, but then I'm o= bviously biased. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 17 September 2013 16:22 To: Eardley,PL,Philip,TUB8 R; bs7652@att.com; lmap@i= etf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Neither do I (feel strongly either way). However I believe that Configurati= on risks to be also mis-leading, and not consistent with other usages of th= e term in the industry (or on the MA or the MA host). What about "Procedure= " or "MA Procedure"? Dan (speaking as contributor) From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Tuesday, September 17, 2013 5:16 PM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller What do other people think? I don't have a strong feeling either way. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 September 2013 14:51 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller I see that your use of "Instruction" is consistent with its proposed LMAP t= erminology definition. And I have no problem with there being a term with t= hat definition. It would appear that my problem is with the choice of "Instruction" as the = word to apply this definition to. The proposed terminology definition uses "Instruction" in a manner that I d= on't consider completely consistent with the way I generally use the word. In computing, "Instruction" is a very basic, low-level message. Such a mess= age tells the computer to do something very specific. There are many, many = instructions in a computer's "instruction set". I've also seen this term used with other inter-device communication. As wit= h computing "instructions", this sort of communication has many different t= ypes of messages, such that each desired action has its own "instruction". In the absence of actually reading the lmap terminology definition, and for= cing myself to accept that lmap is using this word in what I consider an in= dustry-inconsistent way, I would misinterpret the use of this word (and did= in fact misinterpret it). For me, "instruction" in the context of some of the xml-based WAN configura= tion protocols we're looking at, would map to an RPC (Remote Procedure Call= ), if there were not a terminology definition telling me that I should not = misinterpret the word in this manner. I believe it is problematic to select a term that is so commonly used in th= e industry, and provide it with a definition that is not consistent with th= at common usage. I believe the term could easily be replaced by: MA Configuration: The description of Measurement Tasks to perform and th= e details of the Report to send. The MA Configuration is sent by a Controller to a Measurement Agent. If we wanted to just call this Configuration, we could then add the sentenc= e: Also simply referred to as "Configuration" where the context is clear. Barbara From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Tuesday, September 17, 2013 5:59 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Thanks Barbara. thinking about your process question - we're now trying to write a 'protoco= l model' for the framework doc (rfc4101) - so the protocol will be describe= d at this level. Not sure I fully understood your point about Instruction. I was trying to use it as defined in the terminology <> The Instruction would be a message with - one of more Measurement Tasks - one of more Schedules - one or more Report Channels I guess the first msg from Controller to MA includes all of these. Subseque= nt msgs might only update one of them, for instance the Schedule might get = updated rather more often than the other two items. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 12 September 2013 19:34 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller First a process question: How detailed is this Framework document supposed to be? Is it intended to i= nclude the full list of criteria for a Control Protocol, or will these crit= eria be documented separately? If the first, then I would prefer for the cr= iteria to be more precisely described, and easy to identify as Control Prot= ocol criteria/requirements. If the latter, then I would prefer for the Fram= ework to use more descriptive language as to what is expected of the Contro= l Protocol, rather than trying to give names to all of the various expected= functionality (e.g., Instruction, registration). More detailed comments be= low. Barbara From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, September 12, 2013 11:45 AM To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA an= d Controller Thanks for the nice discussion, I've tried to re-write to reflect where I t= hink we've got to. I also changed the title to: Interactions between MA and Controller As part of a bootstrap process the MA gets sufficient information to contac= t a Controller. Defining a bootstrap mechanism is out of scope of the LMAP = WG. The basic interaction between a Controller and MA is that the Controller se= nds an Instruction to the MA, detailing what Measurement Tasks to do, when = to do them, and how to report the Measurement Results. In general we expect= that the measurement system understands what Measurement Methods the MA ca= n do and therefore the Controller can simply instruct the MA; there is no n= eed for a negotiation protocol (which would add complexity to the MA, Contr= oller and Control Protocol). However, it is possible that the MA is in fact= not capable of performing the requested Measurement Method, and so the Con= trol Protocol must allow the MA to reply with a suitable error code. The use of the word "Instruction" here makes me uncomfortable, becaus= e it implies (at least to me) a manner of communication that is not quite c= onsistent with the way most WAN-based massive-number-of-controlled-devices = control protocols work today. "Instruction" suggests a manner of communicat= ion where the desired action is a part of the basic message. Having separat= e message syntax (actions) for everything the Controller wants the MA to do= would greatly increase the number of messages that need to go back and for= th between MA and controller. This sort of interaction is common in protoco= ls intended to work on LAN segments. It's a very bad idea for protocols int= ended to work over the WAN that are intended to scale to large numbers of d= evices, and be highly extensible. I would prefer if we did not attempt to g= ive this function of the Controller to MA interaction a proper name (denote= d by a capital first letter). I would also prefer if we described it as "th= e Controller configures the MA", using the word "configure" instead of "ins= truct". I don't think we've defined "negotiation protocol". Probably because we don= 't need it. I would prefer if we got rid of that (negotiation protocol) sen= tence and just used the last sentence as a positive statement about what we= do expect from the Control Protocol. For example: The Control Protocol mus= t support robust error reporting by the MA, to provide the Controller with = sufficiently-detailed reasons for any failures in configuration. Is "measurement system" defined? I'm a bit unclear on what this is. Resulting recommended text: The basic interaction between a Controller and MA is that the Controller co= nfigures the MA, detailing what Measurement Tasks to do, when to do them, a= nd how to report the Measurement Results. In general we expect that the Con= troller knows what Measurement Methods the MA supports, such that the Contr= oller can correctly configure the MA. However, the Control Protocol must su= pport robust error reporting by the MA, to provide the Controller with suff= iciently-detailed reasons for any failures in configuration. The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] as part of the MA registering with the Controller. Note that in some sc= enarios it is not needed, as the Controller will know the information by ot= her means, for example as part of the bootstrapping process (using Tr-069 s= ay) or because the MA is statically configured. [2] so the MA can re-register, for example if it becomes capable of a new M= easurement Method. ** Comment: suggest we keep it simple and just send the complete list, rath= er than a delta. The message should be short, since Methods are referred to= via a registry. [3] when requested by the Controller, which could be useful if 'something g= oes wrong' and the Controller forgets what the MA can do. The word "register" also makes me uncomfortable, though not as much a= s "Instruct". This implies to me some very specific functionality than I do= n't consider completely necessary. But maybe if "registration" were defined= I would feel better about it. The "**Comment" suggestion is too specific f= or the Framework, IMO. But if Framework has detailed Control Protocol crite= ria, then I would reword the statement as "The Control Protocol must allow = the Controller to request the MA supply the MA's complete list of supported= Measurement Methods, in a concise format." I would prefer if the above st= atements were reworded as: The MA can send to the Controller the list of Measurement Methods that it i= s capable of. This could be useful: [1] when the MA first communicates with a Controller. [2] when the MA becomes capable of a new Measurement Method. [3] when requested by the Controller (e.g., if the Controller forgets what = the MA can do or otherwise wants to resynchronize what it knows about the M= A). Note that the advert contains the list of Measurement Methods that the MA c= an perform. It is not intended to indicate dynamic capabilities like the MA= 's currently unused CPU, memory or battery life. ** Comment: I'm not sure whether we reached consensus on this point. I would have no objection to including such capabilities as optional = elements of the information model. In fact, I think it would be a good idea= . But I don't think this needs to be mentioned in the Framework. It is possible that later, when a MA is implementing the Instruction, it do= es not perform a particular Measurement Task for some reason, such as: the = Measurement Peer is busy, or there is cross-traffic, ... The MA doesn't inf= orm the Controller, instead it is reported to the Collector as part of the = Measurement Report. The Collector may in turn tell the measurement system o= r even the Controller, but this is out of scope of LMAP. ** Comment: are there any conditions when it's critical for the Controller = to be informed? Ditto my previous objection to "Instruction". I believe the informati= on model needs to include status parameters that would allow the Controller= to request this info, at some level. This can be optional to support for M= A and Controller. I recommend rewording to: It is possible that an MA is unable to carry out a configured Measurement T= ask. Possible reasons include the Measurement Peer being busy, presence of = cross-traffic, ... The MA will report this information to the Collector as = part of the Measurement Report. The Collector may in turn tell other system= s (including, possibly, the Controller), but this is out of scope of LMAP. = The MA may also be able to inform the Controller directly of such occurrenc= es. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 September 2013 11:13 To: lmap@ietf.org Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Contr= oller Another issue: There is no negotiation between the MA and Controller - the Controller simp= ly sends the Instruction to the MA, with the details of the Measurement Tas= ks to perform. In general we expect that the measurement system understands the capabiliti= es of its MAs (probably there are only one or a few classes of MA), so nego= tiation about the MA's capabilities would have little benefit. It would als= o add complexity to the MA, Controller and Control Protocol. It is possible that the MA can't perform the requested Measurement Task. So= the Control Protocol needs to allow the MA to reply with an error code. It= has also been suggested that the Controller should be able to ask the MA t= o send a list of all the Measurement Methods that it is capable of, in case= 'something goes wrong' and the Controller forgets what the MA can do. Comm= ent: this idea hasn't had much discussion yet, but appears in the Informati= on Model i-d Thoughts? Thanks phil --_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C1F72podcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m hoping the g= roup assumes Interoperability as a significantly high priority here.

 

   If we eve= r hope to have a DSL modem, or Cable modem, wireless phone, …. To be = delivered with MA capabilities it really must have a standard command set o= r we’ll end up with code variants that inhibit interop.

 

So I’m leaning t= o a common command set – I don’t care what you call it, but it = needs to be standard across the board.

 

 

 

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.com
Sent: Tuesday, September 17, 2013 11:21 AM
To: dromasca@avaya.com; philip.eardley@bt.com; bs7652@att.com; lmap@= ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

To give= a bit of reasoning while I selected “Instruction” to start wit= h…

&n= bsp;

<= span style=3D"mso-list:Ignore">-          There is also a configuration command/information about the general settin= gs of the MA (such as MA ID, Group ID etc.). So configuration is taken (unl= ess we change that as well)

<= span style=3D"mso-list:Ignore">-          It is specifically about getting the MA to do something – either con= duct measurements and produce reports. The stuff in “Configuration= 221; doesn’t result in anything actually being done.

&n= bsp;

I think= “instruction” is pretty descriptive and appropriate, but then = I’m obviously biased.

&n= bsp;

Trevor.=

&n= bsp;

Trevor Bu= rbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this infor= mation is prohibited. If you've received this email in error, please let me= know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: 17 September 2013 16:22
To: Eardley,PL,Philip,TUB8 R; bs76= 52@att.com; lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

Neither do I (feel str= ongly either way). However I believe that Configuration risks to be also mi= s-leading, and not consistent with other usages of the term in the industry= (or on the MA or the MA host). What about “Procedure” or “MA Procedure”?

 

Dan<= /p>

(speaking as contribut= or)

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Tuesday, September 17, 2013 5:16 PM
To: bs7652@att.com; lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

What do other p= eople think?

I don’t h= ave a strong feeling either way.

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: 17 September 2013 14:51
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

I see that your use of= “Instruction” is consistent with its proposed LMAP terminology= definition. And I have no problem with there being a term with that defini= tion.

 

It would appear that m= y problem is with the choice of “Instruction” as the word to ap= ply this definition to.

 

The proposed terminolo= gy definition uses “Instruction” in a manner that I don’t= consider completely consistent with the way I generally use the word.=

In computing, “I= nstruction” is a very basic, low-level message. Such a message tells = the computer to do something very specific. There are many, many instructio= ns in a computer’s “instruction set”.

I’ve also seen t= his term used with other inter-device communication. As with computing R= 20;instructions”, this sort of communication has many different types= of messages, such that each desired action has its own “instruction”.

In the absence of actu= ally reading the lmap terminology definition, and forcing myself to accept = that lmap is using this word in what I consider an industry-inconsistent wa= y, I would misinterpret the use of this word (and did in fact misinterpret it).

For me, “instruc= tion” in the context of some of the xml-based WAN configuration proto= cols we’re looking at, would map to an RPC (Remote Procedure Call), i= f there were not a terminology definition telling me that I should not misinterpret the word in this manner.

I believe it is proble= matic to select a term that is so commonly used in the industry, and provid= e it with a definition that is not consistent with that common usage.<= /o:p>

 

I believe the term cou= ld easily be replaced by:

   MA Configuration: The description of Measurem= ent Tasks to perform and the

   details of the Report to send.  The MA C= onfiguration is sent by a

   Controller to a Measurement Agent.

 

If we wanted to just c= all this Configuration, we could then add the sentence:

Also simply referred to as “Configuration” whe= re the context is clear.

 

Barbara

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Tuesday, September 17, 2013 5:59 AM
To: STARK, BARBARA H; lmap@ietf.org=
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

Thanks Barbara.=

thinking about = your process question – we’re now trying to write a ‘prot= ocol model’ for the framework doc (rfc4101) – so the protocol w= ill be described at this level.

 

Not sure I full= y understood your point about Instruction.

I was trying to= use it as defined in the terminology

<<=
Instruction: The description o=
f Measurement Tasks to perform and the

  = ; details of the Report to send.  The Instruction is sent by a

  = ; Controller to a Measurement Agent.

>> = ;

 <= /span>

The Instruction wo= uld be a message with

-one of mor= e Measurement Tasks

-one of mor= e Schedules

-one or mor= e Report Channels

I guess the first = msg from Controller to MA includes all of these. Subsequent msgs might only= update one of them, for instance the Schedule might get updated rather more often than the other two items.

 <= /span>

  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =    

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: 12 September 2013 19:34
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

First a process questi= on:

How detailed is this F= ramework document supposed to be? Is it intended to include the full list o= f criteria for a Control Protocol, or will these criteria be documented sep= arately? If the first, then I would prefer for the criteria to be more precisely described, and easy to identi= fy as Control Protocol criteria/requirements. If the latter, then I would p= refer for the Framework to use more descriptive language as to what is expe= cted of the Control Protocol, rather than trying to give names to all of the various expected functionality (e.= g., Instruction, registration). More detailed comments below.

Barbara

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Thursday, September 12, 2013 11:45 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 (take 2) Interactions betwee= n MA and Controller

 

Thanks for the nice d= iscussion, I’ve tried to re-write to reflect where I think we’v= e got to. I also changed the title to:

 

Interactions between = MA and Controller

As part of a bootstra= p process the MA gets sufficient information to contact a Controller. Defin= ing a bootstrap mechanism is out of scope of the LMAP WG.=

 

The basic interaction= between a Controller and MA is that the Controller sends an Instruction to= the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect that= the measurement system understands what Measurement Methods the MA can do = and therefore the Controller can simply instruct the MA; there is no need f= or a negotiation protocol (which would add complexity to the MA, Controller and Control Protocol). However,= it is possible that the MA is in fact not capable of performing the reques= ted Measurement Method, and so the Control Protocol must allow the MA to re= ply with a suitable error code.

&n= bsp;

<bhs= > The use of the word “Instruction” here makes me uncomforta= ble, because it implies (at least to me) a manner of communication that is = not quite consistent with the way most WAN-based massive-number-of-controll= ed-devices control protocols work today. “Instruction” suggests a manner = of communication where the desired action is a part of the basic message. H= aving separate message syntax (actions) for everything the Controller wants= the MA to do would greatly increase the number of messages that need to go back and forth between MA and controller. This= sort of interaction is common in protocols intended to work on LAN segment= s. It’s a very bad idea for protocols intended to work over the WAN t= hat are intended to scale to large numbers of devices, and be highly extensible. I would prefer if we did not attempt= to give this function of the Controller to MA interaction a proper name (d= enoted by a capital first letter). I would also prefer if we described it a= s “the Controller configures the MA”, using the word “configure” instead of “instru= ct”.

&n= bsp;

I don&#= 8217;t think we’ve defined “negotiation protocol”. Probab= ly because we don’t need it. I would prefer if we got rid of that (ne= gotiation protocol) sentence and just used the last sentence as a positive statement about what we do expect from the Control Protocol. For example: = The Control Protocol must support robust error reporting by the MA, to prov= ide the Controller with sufficiently-detailed reasons for any failures in c= onfiguration.

&n= bsp;

Is R= 20;measurement system” defined? I’m a bit unclear on what this = is.

&n= bsp;

Resulti= ng recommended text:

The bas= ic interaction between a Controller and MA is that the Controller configure= s the MA, detailing what Measurement Tasks to do, when to do them, and how to report the Measurement Results. In general we expect t= hat the Controller knows what Measurement Methods the MA supports, such tha= t the Controller can correctly configure the MA. However, the Control Proto= col must support robust error reporting by the MA, to provide the Controller with sufficiently-detailed reasons fo= r any failures in configuration.

 

The MA can send to th= e Controller the list of Measurement Methods that it is capable of. This co= uld be useful:

[1] as part of the MA= registering with the Controller. Note that in some scenarios it is not nee= ded, as the Controller will know the information by other means, for example as part of the bootstrapping process (using Tr-069 say)= or because the MA is statically configured.

[2] so the MA can re-= register, for example if it becomes capable of a new Measurement Method.

** Comment: suggest w= e keep it simple and just send the complete list, rather than a delta. The = message should be short, since Methods are referred to via a registry.

[3] when requested by= the Controller, which could be useful if ‘something goes wrong’= ; and the Controller forgets what the MA can do.

&n= bsp;

<bhs= > The word “register” also makes me uncomfortable, though no= t as much as “Instruct”. This implies to me some very specific = functionality than I don’t consider completely necessary. But maybe if “registration” were defined I would feel better about it. T= he “**Comment” suggestion is too specific for the Framework, IM= O. But if Framework has detailed Control Protocol criteria, then I would re= word the statement as “The Control Protocol must allow the Controller to request the MA supply the MA’s complete list of suppor= ted Measurement Methods, in a concise format.”  I would prefer i= f the above statements were reworded as:

The MA = can send to the Controller the list of Measurement Methods that it is capab= le of. This could be useful:

[1] whe= n the MA first communicates with a Controller.

[2] whe= n the MA becomes capable of a new Measurement Method.

[3] whe= n requested by the Controller (e.g., if the Controller forgets what the MA = can do or otherwise wants to resynchronize what it knows about the MA).

 

Note that the advert = contains the list of Measurement Methods that the MA can perform. It is not= intended to indicate dynamic capabilities like the MA’s currently unused CPU, memory or battery life.

** Comment: I’m= not sure whether we reached consensus on this point.

&n= bsp;

<bhs= > I would have no objection to including such capabilities as optional e= lements of the information model. In fact, I think it would be a good idea.= But I don’t think this needs to be mentioned in the Framework.

 

It is possible that l= ater, when a MA is implementing the Instruction, it does not perform a part= icular Measurement Task for some reason, such as: the Measurement Peer is busy, or there is cross-traffic, … The MA doesn’t info= rm the Controller, instead it is reported to the Collector as part of the M= easurement Report. The Collector may in turn tell the measurement system or= even the Controller, but this is out of scope of LMAP.

** Comment: are there= any conditions when it’s critical for the Controller to be informed?=

&n= bsp;

<bhs= > Ditto my previous objection to “Instruction”. I believe th= e information model needs to include status parameters that would allow the= Controller to request this info, at some level. This can be optional to support for MA and Controller. I recommend rewording to:

It is p= ossible that an MA is unable to carry out a configured Measurement Task. Po= ssible reasons include the Measurement Peer being busy, presence of cross-traffic, … The MA will report this information to the Colle= ctor as part of the Measurement Report. The Collector may in turn tell othe= r systems (including, possibly, the Controller), but this is out of scope o= f LMAP. The MA may also be able to inform the Controller directly of such occurrences.

&n= bsp;

 

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 05 September 2013 11:13
To: lmap@ietf.org
Subject: [lmap] LMAP Framework issue #3 No negotiation between MA an= d Controller

 

Another issue:

There is no negotiati= on between the MA and Controller - the Controller simply sends the Instruct= ion to the MA, with the details of the Measurement Tasks to perform.

In general we expect = that the measurement system understands the capabilities of its MAs (probab= ly there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. It would also= add complexity to the MA, Controller and Control Protocol.

 

It is possible that t= he MA can’t perform the requested Measurement Task. So the Control Pr= otocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to se= nd a list of all the Measurement Methods that it is capable of, in case = 216;something goes wrong’ and the Controller forgets what the MA can = do. Comment: this idea hasn’t had much discussion yet, but appears in the Information Model i-d

 

Thoughts?

Thanks

phil

--_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C1F72podcwmbxex505ct_-- From bs7652@att.com Tue Sep 17 12:06:03 2013 Return-Path: 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 755E011E813B for ; Tue, 17 Sep 2013 12:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.832 X-Spam-Level: X-Spam-Status: No, score=-6.832 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 GyPAFOtxkTAL for ; Tue, 17 Sep 2013 12:05:56 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E74D411E812E for ; Tue, 17 Sep 2013 12:05:05 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 1e7a8325.7cc5b940.2071572.00-534.5722443.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 17 Sep 2013 19:05:05 +0000 (UTC) X-MXL-Hash: 5238a7e14f2c7054-c07e6463462cbe02fd9cd0bc4524c088c10e499d Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ec7a8325.0.2071290.00-470.5721691.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 17 Sep 2013 19:04:47 +0000 (UTC) X-MXL-Hash: 5238a7cf568b06ef-5aed6271f94978db6164ce9017c51315c5a33dd0 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8HJ4jgd023183; Tue, 17 Sep 2013 15:04:46 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8HJ4bJN023030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 15:04:42 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 17 Sep 2013 19:04:28 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0158.001; Tue, 17 Sep 2013 15:04:26 -0400 From: "STARK, BARBARA H" To: "Bugenhagen, Michael K" , "'trevor.burbridge@bt.com'" , "dromasca@avaya.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAAD0AhwAAAihGAAAgLhkAAB2+XAAAIQbgA= Date: Tue, 17 Sep 2013 19:04:24 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.92.168] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130370CEAGAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=WrCcx6jv c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=D1WqCaXvWwIA:10 a=l4EBnxoveaQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Lb5Mp4LI0] X-AnalysisOut: [xsA:10 a=kAwF98ykFRanaQaJz7IA:9 a=CjuIK1q_8ugA:10 a=scQuHj] X-AnalysisOut: [9IZ0H3bBXp:21 a=I6vEsQGr0UfFtjKA:21 a=yMhMjlubAAAA:8 a=SSm] X-AnalysisOut: [OFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk] X-AnalysisOut: [6K0A:10 a=frz4AuCg-hUA:10 a=-w9Ry6k9uwuLkrSv:21] Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 19:06:03 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130370CEAGAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike said: I'm hoping the group assumes Interoperability as a significantly high prior= ity here. If we ever hope to have a DSL modem, or Cable modem, wireless phone, ...= . To be delivered with MA capabilities it really must have a standard comma= nd set or we'll end up with code variants that inhibit interop. So I'm leaning to a common command set - I don't care what you call it, but= it needs to be standard across the board. I disagree strongly. Certainly the Measurement Methods need to be tot= ally interoperable -- but definition of those comes from ippm. That's not p= art of the "command set" we're talking about. I believe very strongly that there is absolutely no requirement for the MAs= procured by a DSL provider be controllable by the Controllers of a Cable o= perator. Nor that a provider's wireless devices be controllable by the same= Controller as that provider's DSL modems. This, for me, was one of the big= reasons for scoping this effort to MA and Controller belonging to the same= domain/entity. Interoperability that needs to be guaranteed across entitie= s (such as the Measurement Methods) requires the level of standardization y= ou suggest. Interoperability internal to an entity can be defined and ensur= ed by that entity. The criteria regarding what makes for a good Control or Collector protocol = must not include a requirement that all protocols used for these purposes h= ave a common command set -- there is no justification I can think of to be = that prescriptive. A protocol that meets these criteria should be expected = to have a well-defined command set. But that really should go without sayin= g -- that's obvious. I fully expect that whatever IETF protocols LMAP chooses to recommend (that= meet the criteria) will have a very specific and extremely well-defined co= mmand set. So any provider who wants to use that recommended protocol shoul= d be able to expect a certain degree of interoperability. Though, in my exp= erience, if there is no certification program or test tools to ensure compl= iance with that protocol's specification, the provider may still need to pu= t in a fair amount of effort and testing to ensure a satisfactory degree of= interoperability between their procured MAs and Controller (assuming they = come from different vendors -- single vendor selection tends to require les= s testing). The provider will probably take into account how knowledgeable = and experienced their own test labs are with the protocol they select for u= se between their MAs and Controllers. Likewise, 3rd parties will make selec= tions based on what makes sense for them. Barbara --_000_2D09D61DDFA73D4C884805CC7865E61130370CEAGAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike said:

I’m hoping the g= roup assumes Interoperability as a significantly high priority here.

 

   If we eve= r hope to have a DSL modem, or Cable modem, wireless phone, …. To be = delivered with MA capabilities it really must have a standard command set o= r we’ll end up with code variants that inhibit interop.

 

So I’m leaning to a common command set – I don’t c= are what you call it, but it needs to be standard across the board.<= span style=3D"color:#1F497D">

 

<bhs> I disagree strongly. Certainly the Measu= rement Methods need to be totally interoperable -- but definition of those = comes from ippm. That’s not part of the “command set” we&= #8217;re talking about.

 

I believe very strongly that there is absolutely no = requirement for the MAs procured by a DSL provider be controllable by the C= ontrollers of a Cable operator. Nor that a provider’s wireless device= s be controllable by the same Controller as that provider’s DSL modems. This, for me, was one of the big reas= ons for scoping this effort to MA and Controller belonging to the same doma= in/entity. Interoperability that needs to be guaranteed across entities (su= ch as the Measurement Methods) requires the level of standardization you suggest. Interoperability internal to an = entity can be defined and ensured by that entity.

 

The criteria regarding what makes for a good Control= or Collector protocol must not include a requirement that all protocols us= ed for these purposes have a common command set -- there is no justificatio= n I can think of to be that prescriptive. A protocol that meets these criteria should be expected to have a well-def= ined command set. But that really should go without saying -- that’s = obvious.

 

I fully expect that whatever IETF protocols LMAP cho= oses to recommend (that meet the criteria) will have a very specific and ex= tremely well-defined command set. So any provider who wants to use that rec= ommended protocol should be able to expect a certain degree of interoperability. Though, in my experience, if = there is no certification program or test tools to ensure compliance with t= hat protocol’s specification, the provider may still need to put in a= fair amount of effort and testing to ensure a satisfactory degree of interoperability between their procured MA= s and Controller (assuming they come from different vendors -- single vendo= r selection tends to require less testing). The provider will probably take= into account how knowledgeable and experienced their own test labs are with the protocol they select for = use between their MAs and Controllers. Likewise, 3rd parties wil= l make selections based on what makes sense for them.

Barbara

 

--_000_2D09D61DDFA73D4C884805CC7865E61130370CEAGAALPA1MSGUSR9L_-- From Michael.K.Bugenhagen@centurylink.com Tue Sep 17 12:43:15 2013 Return-Path: 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 601EF11E855C for ; Tue, 17 Sep 2013 12:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 7sWak4SNeuBV for ; Tue, 17 Sep 2013 12:43:08 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id AE74811E855B for ; Tue, 17 Sep 2013 12:43:08 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r8HJh2NV012696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 14:43:02 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 1188B1E006C; Tue, 17 Sep 2013 14:42:57 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id CA8E41E0067; Tue, 17 Sep 2013 14:42:56 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r8HJguAD007424; Tue, 17 Sep 2013 13:42:56 -0600 (MDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r8HJgtY1007413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Sep 2013 13:42:56 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.02.0318.001; Tue, 17 Sep 2013 14:42:55 -0500 From: "Bugenhagen, Michael K" To: "'STARK, BARBARA H'" , "'trevor.burbridge@bt.com'" , "dromasca@avaya.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAAD0AhwAAAihGAAAgLhkAAB2+XAAAIQbgAAApZn0A== Date: Tue, 17 Sep 2013 19:42:54 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C23EEpodcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 19:43:15 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C23EEpodcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barbara - I don't think we discussing the same inter-operability levels. We have - MA to MA MC to MA Stand alone MA in a home environment Technology CPE (Service Provider or Customer Provided) All of these have one single thing in common - We want the test results to= match. That cannot happen if we don't describe the testing sufficiently enough t= o ensure the "probe implementation" requirements are stateable, and testabl= e. Otherwise when a new test is constructed, we can't say that any one of the = different technology devices can support running that test, and compare DSL= , to Cable, to Satellite to LTE, ..... So if apples to apples results aren't a very high requirement I need to res= et my thinking... From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Tuesday, September 17, 2013 2:04 PM To: Bugenhagen, Michael K; 'trevor.burbridge@bt.com'; dromasca@avaya.com; p= hilip.eardley@bt.com; lmap@ietf.org Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions between M= A and Controller Mike said: I'm hoping the group assumes Interoperability as a significantly high prior= ity here. If we ever hope to have a DSL modem, or Cable modem, wireless phone, ...= . To be delivered with MA capabilities it really must have a standard comma= nd set or we'll end up with code variants that inhibit interop. So I'm leaning to a common command set - I don't care what you call it, but= it needs to be standard across the board. I disagree strongly. Certainly the Measurement Methods need to be tot= ally interoperable -- but definition of those comes from ippm. That's not p= art of the "command set" we're talking about. I believe very strongly that there is absolutely no requirement for the MAs= procured by a DSL provider be controllable by the Controllers of a Cable o= perator. Nor that a provider's wireless devices be controllable by the same= Controller as that provider's DSL modems. This, for me, was one of the big= reasons for scoping this effort to MA and Controller belonging to the same= domain/entity. Interoperability that needs to be guaranteed across entitie= s (such as the Measurement Methods) requires the level of standardization y= ou suggest. Interoperability internal to an entity can be defined and ensur= ed by that entity. The criteria regarding what makes for a good Control or Collector protocol = must not include a requirement that all protocols used for these purposes h= ave a common command set -- there is no justification I can think of to be = that prescriptive. A protocol that meets these criteria should be expected = to have a well-defined command set. But that really should go without sayin= g -- that's obvious. I fully expect that whatever IETF protocols LMAP chooses to recommend (that= meet the criteria) will have a very specific and extremely well-defined co= mmand set. So any provider who wants to use that recommended protocol shoul= d be able to expect a certain degree of interoperability. Though, in my exp= erience, if there is no certification program or test tools to ensure compl= iance with that protocol's specification, the provider may still need to pu= t in a fair amount of effort and testing to ensure a satisfactory degree of= interoperability between their procured MAs and Controller (assuming they = come from different vendors -- single vendor selection tends to require les= s testing). The provider will probably take into account how knowledgeable = and experienced their own test labs are with the protocol they select for u= se between their MAs and Controllers. Likewise, 3rd parties will make selec= tions based on what makes sense for them. Barbara --_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C23EEpodcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Barbara –

 

   &nbs= p; I don’t think we discussing the same inter-operability levels.

 

We have –

 

MA to MA

MC to MA

Stand alone MA in a ho= me environment

Technology CPE (Servic= e Provider or Customer Provided)

 

All of these have one = single thing in common -  We want the test results to match.

  That cannot hap= pen if we don’t describe the testing sufficiently enough to ensure th= e “probe implementation” requirements are stateable, and testab= le.

 

Otherwise when a new t= est is constructed, we can’t say that any one of the different techno= logy devices can support running that test, and compare DSL, to Cable, to S= atellite to LTE, …..

So if apples to apples= results aren’t a very high requirement I need to reset my thinking&#= 8230;

 

   &nbs= p;

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Tuesday, September 17, 2013 2:04 PM
To: Bugenhagen, Michael K; 'trevor.burbridge@bt.com'; dromasca@avaya= .com; philip.eardley@bt.com; lmap@ietf.org
Subject: RE: [lmap] LMAP Framework issue #3 (take 2) Interactions be= tween MA and Controller

 

Mike said:

I’m hoping the g= roup assumes Interoperability as a significantly high priority here.

 

   If we eve= r hope to have a DSL modem, or Cable modem, wireless phone, …. To be = delivered with MA capabilities it really must have a standard command set o= r we’ll end up with code variants that inhibit interop.

 

So I’m leaning to a common command set – I don’t c= are what you call it, but it needs to be standard across the board.

 

<bhs> I disagree strongly. Certainly the Measu= rement Methods need to be totally interoperable -- but definition of those = comes from ippm. That’s not part of the “command set” we&= #8217;re talking about.

 

I believe very strongly that there is absolutely no = requirement for the MAs procured by a DSL provider be controllable by the C= ontrollers of a Cable operator. Nor that a provider’s wireless device= s be controllable by the same Controller as that provider’s DSL modems. This, for me, was one of the big reas= ons for scoping this effort to MA and Controller belonging to the same doma= in/entity. Interoperability that needs to be guaranteed across entities (su= ch as the Measurement Methods) requires the level of standardization you suggest. Interoperability internal to an = entity can be defined and ensured by that entity.

 

The criteria regarding what makes for a good Control= or Collector protocol must not include a requirement that all protocols us= ed for these purposes have a common command set -- there is no justificatio= n I can think of to be that prescriptive. A protocol that meets these criteria should be expected to have a well-def= ined command set. But that really should go without saying -- that’s = obvious.

 

I fully expect that whatever IETF protocols LMAP cho= oses to recommend (that meet the criteria) will have a very specific and ex= tremely well-defined command set. So any provider who wants to use that rec= ommended protocol should be able to expect a certain degree of interoperability. Though, in my experience, if = there is no certification program or test tools to ensure compliance with t= hat protocol’s specification, the provider may still need to put in a= fair amount of effort and testing to ensure a satisfactory degree of interoperability between their procured MA= s and Controller (assuming they come from different vendors -- single vendo= r selection tends to require less testing). The provider will probably take= into account how knowledgeable and experienced their own test labs are with the protocol they select for = use between their MAs and Controllers. Likewise, 3rd parties wil= l make selections based on what makes sense for them.

Barbara

 

--_000_A68F3CAC468B2E48BB775ACE2DD99B5E047C23EEpodcwmbxex505ct_-- From bs7652@att.com Tue Sep 17 15:11:22 2013 Return-Path: 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 A4AF611E81BA for ; Tue, 17 Sep 2013 15:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.773 X-Spam-Level: X-Spam-Status: No, score=-6.773 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 ESJDqj1yj1+1 for ; Tue, 17 Sep 2013 15:11:15 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBD911E82E9 for ; Tue, 17 Sep 2013 15:11:12 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 383d8325.2aaabce8f940.2206624.00-573.6097362.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 17 Sep 2013 22:11:15 +0000 (UTC) X-MXL-Hash: 5238d3830fe1df69-9449bfd094d9a46b886fd99634beedb59aa8ac99 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 973d8325.0.2206604.00-477.6097069.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 17 Sep 2013 22:11:06 +0000 (UTC) X-MXL-Hash: 5238d37a0fb001ad-685d84bf0e23121b1bddd924196eacb3ac5d5caa Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8HMB5Gq008700; Tue, 17 Sep 2013 18:11:05 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8HMAmtY008537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 18:10:57 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (GAALPA1MSGHUB9F.itservices.sbc.com [130.8.36.92]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 17 Sep 2013 22:10:38 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.03.0158.001; Tue, 17 Sep 2013 18:10:38 -0400 From: "STARK, BARBARA H" To: "Bugenhagen, Michael K" , "'trevor.burbridge@bt.com'" , "dromasca@avaya.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAAD0AhwAAAihGAAAgLhkAAB2+XAAAIQbgAAApZn0AAFVZbA Date: Tue, 17 Sep 2013 22:10:37 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130370E17@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.92.168] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130370E17GAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=WrCcx6jv c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=D1WqCaXvWwIA:10 a=l4EBnxoveaQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Lb5Mp4LI0] X-AnalysisOut: [xsA:10 a=aaWEiV_FPh-uQcBVPIsA:9 a=CjuIK1q_8ugA:10 a=yMhMjl] X-AnalysisOut: [ubAAAA:8 a=SSmOFEACAAAA:8 a=yLF1E_JogU_pY4Fz4bUA:9 a=gKO2H] X-AnalysisOut: [q4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-] X-AnalysisOut: [hUA:10 a=eqHPBJTQDdmiGap2:21] Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 22:11:22 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130370E17GAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barbara - I don't think we discussing the same inter-operability levels. We have - MA to MA MC to MA Stand alone MA in a home environment Technology CPE (Service Provider or Customer Provided) All of these have one single thing in common - We want the test results to= match. That cannot happen if we don't describe the testing sufficiently enough t= o ensure the "probe implementation" requirements are stateable, and testabl= e. Otherwise when a new test is constructed, we can't say that any one of the = different technology devices can support running that test, and compare DSL= , to Cable, to Satellite to LTE, ..... So if apples to apples results aren't a very high requirement I need to res= et my thinking... The command set (if I understand what you mean by that term) of a Con= troller to MA protocol has no impact on ensuring matching test results. Hav= ing a common information model that reflects a common set of well-defined M= easurement Methods is what is needed to ensure matching test results. This = is why we need to focus really hard on getting the Information Model well-d= efined. If that Information Model is accurately reflected in the data model= s of a dozen different protocols, defined by a dozen different SDOs or SIGs= , and these protocols all meet a set of criteria for suitability to the tas= k of being a good Control Protocol, then it doesn't matter which of these p= rotocols an entity chooses to use between its Controller and its MAs. Again, I understand that LMAP intends to recommend what this group believes= to be the right IETF-defined protocol to use as a Control Protocol. I get = that. Really I do. All I want is that RFCs don't get published that suggest= this recommended protocol is the only possible suitable protocol. Therefor= e, specific command syntax is not appropriate in the framework as part of d= escribing desired Control Protocol characteristics. Barbara --_000_2D09D61DDFA73D4C884805CC7865E61130370E17GAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Barbara –

 

   &nbs= p; I don’t think we discussing the same inter-operability levels.

 

We have –

 

MA to MA

MC to MA

Stand alone MA in a ho= me environment

Technology CPE (Servic= e Provider or Customer Provided)

 

All of these have one = single thing in common -  We want the test results to match.

  That cannot hap= pen if we don’t describe the testing sufficiently enough to ensure th= e “probe implementation” requirements are stateable, and testab= le.

 

Otherwise when a new t= est is constructed, we can’t say that any one of the different techno= logy devices can support running that test, and compare DSL, to Cable, to S= atellite to LTE, …..

So if apples to apples= results aren’t a very high requirement I need to reset my thinking&#= 8230;

 

<bhs> The command set (if I understand what yo= u mean by that term) of a Controller to MA protocol has no impact on ensuri= ng matching test results. Having a common information model that reflects a= common set of well-defined Measurement Methods is what is needed to ensure matching test results. This is why we = need to focus really hard on getting the Information Model well-defined. If= that Information Model is accurately reflected in the data models of a doz= en different protocols, defined by a dozen different SDOs or SIGs, and these protocols all meet a set of c= riteria for suitability to the task of being a good Control Protocol, then = it doesn’t matter which of these protocols an entity chooses to use b= etween its Controller and its MAs.

 

Again, I understand that LMAP intends to recommend w= hat this group believes to be the right IETF-defined protocol to use as a C= ontrol Protocol. I get that. Really I do. All I want is that RFCs don’= ;t get published that suggest this recommended protocol is the only possible suitable protocol. Therefore, specific comma= nd syntax is not appropriate in the framework as part of describing desired= Control Protocol characteristics.

Barbara

--_000_2D09D61DDFA73D4C884805CC7865E61130370E17GAALPA1MSGUSR9L_-- From marcelo@it.uc3m.es Tue Sep 17 22:39:34 2013 Return-Path: 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 E2BBD11E8114 for ; Tue, 17 Sep 2013 22:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.999 X-Spam-Level: X-Spam-Status: No, score=-106.999 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 bSwip1A+lNq5 for ; Tue, 17 Sep 2013 22:39:29 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id D35BE11E8111 for ; Tue, 17 Sep 2013 22:39:26 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 50EC7FA97F7 for ; Wed, 18 Sep 2013 07:39:25 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost25.it.uc3m.es (unknown [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 304CD9D7119 for ; Wed, 18 Sep 2013 07:39:25 +0200 (CEST) Message-ID: <52393C9B.9000007@it.uc3m.es> Date: Wed, 18 Sep 2013 07:39:39 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C8AAC21A30@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8AAC21A30@njfpsrvexg8.research.att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Wed, 18 Sep 2013 07:39:25 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20158.001 X-TM-AS-Result: No--40.063-7.0-31-1 X-imss-scan-details: No--40.063-7.0-31-1 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 05:39:34 -0000 I guess i am biassed as well, but configuration, should be used for the initial configuration of the MA, while instruction seems like a specific thing that the MA is instructed to perform. El 17/09/13 18:43, MORTON, ALFRED C (AL) escribió: > > … > > I think “instruction” is pretty descriptive and appropriate, but then > I’m obviously biased. > > Trevor. > > +1, and if there's still confusion, add the adjective "Measurement". > > I've been using this term frequently in writing assignments, > > and it hasn't tripped me up yet (which reminds me, > > it's the term we used in the lmap charter, too). > > Al > > *From:*lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] *On Behalf > Of *trevor.burbridge@bt.com > *Sent:* Tuesday, September 17, 2013 12:21 PM > *To:* dromasca@avaya.com; philip.eardley@bt.com; STARK, BARBARA H; > lmap@ietf.org > *Subject:* Re: [lmap] LMAP Framework issue #3 (take 2) Interactions > between MA and Controller > > To give a bit of reasoning while I selected “Instruction” to start with… > > -There is also a configuration command/information about the general > settings of the MA (such as MA ID, Group ID etc.). So configuration is > taken (unless we change that as well) > > -It is specifically about getting the MA to do something – either > conduct measurements and produce reports. The stuff in “Configuration” > doesn’t result in anything actually being done. > > I think “instruction” is pretty descriptive and appropriate, but then > I’m obviously biased. > > Trevor. > > *Trevor Burbridge > Network Infrastructure & Innovation | BT Innovate & Design > Tel: 01473 645115 > Fax: 01473 640929 > * > This email contains BT information, which may be privileged or > confidential. It's meant only for the individual(s) or entity named > above. If you're not the intended recipient, note that disclosing, > copying, distributing or using this information is prohibited. If > you've received this email in error, please let me know immediately on > the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > *From:*lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] *On Behalf > Of *Romascanu, Dan (Dan) > *Sent:* 17 September 2013 16:22 > *To:* Eardley,PL,Philip,TUB8 R; bs7652@att.com; lmap@ietf.org > *Subject:* Re: [lmap] LMAP Framework issue #3 (take 2) Interactions > between MA and Controller > > Neither do I (feel strongly either way). However I believe that > Configuration risks to be also mis-leading, and not consistent with > other usages of the term in the industry (or on the MA or the MA > host). What about “Procedure” or “MA Procedure”? > > Dan > > (speaking as contributor) > > *From:*lmap-bounces@ietf.org > [mailto:lmap-bounces@ietf.org] *On Behalf Of *philip.eardley@bt.com > > *Sent:* Tuesday, September 17, 2013 5:16 PM > *To:* bs7652@att.com ; lmap@ietf.org > > *Subject:* Re: [lmap] LMAP Framework issue #3 (take 2) Interactions > between MA and Controller > > What do other people think? > > I don’t have a strong feeling either way. > > *From:*STARK, BARBARA H [mailto:bs7652@att.com] > *Sent:* 17 September 2013 14:51 > *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org > *Subject:* RE: [lmap] LMAP Framework issue #3 (take 2) Interactions > between MA and Controller > > I see that your use of “Instruction” is consistent with its proposed > LMAP terminology definition. And I have no problem with there being a > term with that definition. > > It would appear that my problem is with the choice of “Instruction” as > the word to apply this definition to. > > The proposed terminology definition uses “Instruction” in a manner > that I don’t consider completely consistent with the way I generally > use the word. > > In computing, “Instruction” is a very basic, low-level message. Such a > message tells the computer to do something very specific. There are > many, many instructions in a computer’s “instruction set”. > > I’ve also seen this term used with other inter-device communication. > As with computing “instructions”, this sort of communication has many > different types of messages, such that each desired action has its own > “instruction”. > > In the absence of actually reading the lmap terminology definition, > and forcing myself to accept that lmap is using this word in what I > consider an industry-inconsistent way, I would misinterpret the use of > this word (and did in fact misinterpret it). > > For me, “instruction” in the context of some of the xml-based WAN > configuration protocols we’re looking at, would map to an RPC (Remote > Procedure Call), if there were not a terminology definition telling me > that I should not misinterpret the word in this manner. > > I believe it is problematic to select a term that is so commonly used > in the industry, and provide it with a definition that is not > consistent with that common usage. > > I believe the term could easily be replaced by: > > MA Configuration: The description of Measurement Tasks to perform and the > > details of the Report to send. The MA Configuration is sent by a > > Controller to a Measurement Agent. > > If we wanted to just call this Configuration, we could then add the > sentence: > > Also simply referred to as “Configuration” where the context is clear. > > Barbara > > *From:*philip.eardley@bt.com > [mailto:philip.eardley@bt.com] > *Sent:* Tuesday, September 17, 2013 5:59 AM > *To:* STARK, BARBARA H; lmap@ietf.org > *Subject:* RE: [lmap] LMAP Framework issue #3 (take 2) Interactions > between MA and Controller > > Thanks Barbara. > > thinking about your process question – we’re now trying to write a > ‘protocol model’ for the framework doc (rfc4101) – so the protocol > will be described at this level. > > Not sure I fully understood your point about Instruction. > > I was trying to use it as defined in the terminology > > < > details of the Report to send. The Instruction is sent by a > > Controller to a Measurement Agent. > > >> > > The Instruction would be a message with > > -one of more Measurement Tasks > > -one of more Schedules > > -one or more Report Channels > > I guess the first msg from Controller to MA includes all of these. > Subsequent msgs might only update one of them, for instance the > Schedule might get updated rather more often than the other two items. > > *From:*STARK, BARBARA H [mailto:bs7652@att.com] > *Sent:* 12 September 2013 19:34 > *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org > *Subject:* RE: [lmap] LMAP Framework issue #3 (take 2) Interactions > between MA and Controller > > First a process question: > > How detailed is this Framework document supposed to be? Is it intended > to include the full list of criteria for a Control Protocol, or will > these criteria be documented separately? If the first, then I would > prefer for the criteria to be more precisely described, and easy to > identify as Control Protocol criteria/requirements. If the latter, > then I would prefer for the Framework to use more descriptive language > as to what is expected of the Control Protocol, rather than trying to > give names to all of the various expected functionality (e.g., > Instruction, registration). More detailed comments below. > > Barbara > > *From:*lmap-bounces@ietf.org > [mailto:lmap-bounces@ietf.org] *On Behalf Of *philip.eardley@bt.com > > *Sent:* Thursday, September 12, 2013 11:45 AM > *To:* lmap@ietf.org > *Subject:* [lmap] LMAP Framework issue #3 (take 2) Interactions > between MA and Controller > > Thanks for the nice discussion, I’ve tried to re-write to reflect > where I think we’ve got to. I also changed the title to: > > Interactions between MA and Controller > > As part of a bootstrap process the MA gets sufficient information to > contact a Controller. Defining a bootstrap mechanism is out of scope > of the LMAP WG. > > The basic interaction between a Controller and MA is that the > Controller sends an Instruction to the MA, detailing what Measurement > Tasks to do, when to do them, and how to report the Measurement > Results. In general we expect that the measurement system understands > what Measurement Methods the MA can do and therefore the Controller > can simply instruct the MA; there is no need for a negotiation > protocol (which would add complexity to the MA, Controller and Control > Protocol). However, it is possible that the MA is in fact not capable > of performing the requested Measurement Method, and so the Control > Protocol must allow the MA to reply with a suitable error code. > > The use of the word “Instruction” here makes me uncomfortable, > because it implies (at least to me) a manner of communication that is > not quite consistent with the way most WAN-based > massive-number-of-controlled-devices control protocols work today. > “Instruction” suggests a manner of communication where the desired > action is a part of the basic message. Having separate message syntax > (actions) for everything the Controller wants the MA to do would > greatly increase the number of messages that need to go back and forth > between MA and controller. This sort of interaction is common in > protocols intended to work on LAN segments. It’s a very bad idea for > protocols intended to work over the WAN that are intended to scale to > large numbers of devices, and be highly extensible. I would prefer if > we did not attempt to give this function of the Controller to MA > interaction a proper name (denoted by a capital first letter). I would > also prefer if we described it as “the Controller configures the MA”, > using the word “configure” instead of “instruct”. > > I don’t think we’ve defined “negotiation protocol”. Probably because > we don’t need it. I would prefer if we got rid of that (negotiation > protocol) sentence and just used the last sentence as a positive > statement about what we do expect from the Control Protocol. For > example: The Control Protocol must support robust error reporting by > the MA, to provide the Controller with sufficiently-detailed reasons > for any failures in configuration. > > Is “measurement system” defined? I’m a bit unclear on what this is. > > Resulting recommended text: > > The basic interaction between a Controller and MA is that the > Controller configures the MA, detailing what Measurement Tasks to do, > when to do them, and how to report the Measurement Results. In general > we expect that the Controller knows what Measurement Methods the MA > supports, such that the Controller can correctly configure the MA. > However, the Control Protocol must support robust error reporting by > the MA, to provide the Controller with sufficiently-detailed reasons > for any failures in configuration. > > The MA can send to the Controller the list of Measurement Methods that > it is capable of. This could be useful: > > [1] as part of the MA registering with the Controller. Note that in > some scenarios it is not needed, as the Controller will know the > information by other means, for example as part of the bootstrapping > process (using Tr-069 say) or because the MA is statically configured. > > [2] so the MA can re-register, for example if it becomes capable of a > new Measurement Method. > > ** Comment: suggest we keep it simple and just send the complete list, > rather than a delta. The message should be short, since Methods are > referred to via a registry. > > [3] when requested by the Controller, which could be useful if > ‘something goes wrong’ and the Controller forgets what the MA can do. > > The word “register” also makes me uncomfortable, though not as > much as “Instruct”. This implies to me some very specific > functionality than I don’t consider completely necessary. But maybe if > “registration” were defined I would feel better about it. The > “**Comment” suggestion is too specific for the Framework, IMO. But if > Framework has detailed Control Protocol criteria, then I would reword > the statement as “The Control Protocol must allow the Controller to > request the MA supply the MA’s complete list of supported Measurement > Methods, in a concise format.” I would prefer if the above statements > were reworded as: > > The MA can send to the Controller the list of Measurement Methods that > it is capable of. This could be useful: > > [1] when the MA first communicates with a Controller. > > [2] when the MA becomes capable of a new Measurement Method. > > [3] when requested by the Controller (e.g., if the Controller forgets > what the MA can do or otherwise wants to resynchronize what it knows > about the MA). > > Note that the advert contains the list of Measurement Methods that the > MA can perform. It is not intended to indicate dynamic capabilities > like the MA’s currently unused CPU, memory or battery life. > > ** Comment: I’m not sure whether we reached consensus on this point. > > I would have no objection to including such capabilities as > optional elements of the information model. In fact, I think it would > be a good idea. But I don’t think this needs to be mentioned in the > Framework. > > It is possible that later, when a MA is implementing the Instruction, > it does not perform a particular Measurement Task for some reason, > such as: the Measurement Peer is busy, or there is cross-traffic, … > The MA doesn’t inform the Controller, instead it is reported to the > Collector as part of the Measurement Report. The Collector may in turn > tell the measurement system or even the Controller, but this is out of > scope of LMAP. > > ** Comment: are there any conditions when it’s critical for the > Controller to be informed? > > Ditto my previous objection to “Instruction”. I believe the > information model needs to include status parameters that would allow > the Controller to request this info, at some level. This can be > optional to support for MA and Controller. I recommend rewording to: > > It is possible that an MA is unable to carry out a configured > Measurement Task. Possible reasons include the Measurement Peer being > busy, presence of cross-traffic, … The MA will report this information > to the Collector as part of the Measurement Report. The Collector may > in turn tell other systems (including, possibly, the Controller), but > this is out of scope of LMAP. The MA may also be able to inform the > Controller directly of such occurrences. > > *From:*lmap-bounces@ietf.org > [mailto:lmap-bounces@ietf.org] *On Behalf Of *philip.eardley@bt.com > > *Sent:* 05 September 2013 11:13 > *To:* lmap@ietf.org > *Subject:* [lmap] LMAP Framework issue #3 No negotiation between MA > and Controller > > Another issue: > > There is no negotiation between the MA and Controller - the Controller > simply sends the Instruction to the MA, with the details of the > Measurement Tasks to perform. > > In general we expect that the measurement system understands the > capabilities of its MAs (probably there are only one or a few classes > of MA), so negotiation about the MA’s capabilities would have little > benefit. It would also add complexity to the MA, Controller and > Control Protocol. > > It is possible that the MA can’t perform the requested Measurement > Task. So the Control Protocol needs to allow the MA to reply with an > error code. It has also been suggested that the Controller should be > able to ask the MA to send a list of all the Measurement Methods that > it is capable of, in case ‘something goes wrong’ and the Controller > forgets what the MA can do. Comment: this idea hasn’t had much > discussion yet, but appears in the Information Model i-d > > Thoughts? > > Thanks > > phil > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From marcelo@it.uc3m.es Tue Sep 17 22:50:07 2013 Return-Path: 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 0994C11E8116 for ; Tue, 17 Sep 2013 22:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.666 X-Spam-Level: X-Spam-Status: No, score=-106.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 EmAUdetYfsS7 for ; Tue, 17 Sep 2013 22:50:02 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id D31E011E8129 for ; Tue, 17 Sep 2013 22:50:01 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5E812CB7D60 for ; Wed, 18 Sep 2013 07:49:59 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost25.it.uc3m.es (dummyhost21.it.uc3m.es [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 523EDC3FD52 for ; Wed, 18 Sep 2013 07:49:59 +0200 (CEST) Message-ID: <52393F16.3090904@it.uc3m.es> Date: Wed, 18 Sep 2013 07:50:14 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Wed, 18 Sep 2013 07:49:59 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20158.002 Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 05:50:07 -0000 El 17/09/13 21:04, STARK, BARBARA H escribió: > > Mike said: > > I’m hoping the group assumes Interoperability as a significantly high > priority here. > > If we ever hope to have a DSL modem, or Cable modem, wireless phone, > …. To be delivered with MA capabilities it really must have a standard > command set or we’ll end up with code variants that inhibit interop. > > So I’m leaning to a common command set – I don’t care what you call > it, but it needs to be standard across the board. > > I disagree strongly. Certainly the Measurement Methods need to > be totally interoperable -- but definition of those comes from ippm. > That’s not part of the “command set” we’re talking about. > > I believe very strongly that there is absolutely no requirement for > the MAs procured by a DSL provider be controllable by the Controllers > of a Cable operator. Nor that a provider’s wireless devices be > controllable by the same Controller as that provider’s DSL modems. > This, for me, was one of the big reasons for scoping this effort to MA > and Controller belonging to the same domain/entity. Interoperability > that needs to be guaranteed across entities (such as the Measurement > Methods) requires the level of standardization you suggest. > Interoperability internal to an entity can be defined and ensured by > that entity. > > The criteria regarding what makes for a good Control or Collector > protocol must not include a requirement that all protocols used for > these purposes have a common command set -- there is no justification > I can think of to be that prescriptive. A protocol that meets these > criteria should be expected to have a well-defined command set. But > that really should go without saying -- that’s obvious. > I think the key disagreement here is whether we believe lmap will produce one or more control protocols. If we produce more than one protocol, i agree it doesnt make sense for a controller impelmenting protocol 1 to interoperate with a MA that implements protocol 2. But if both implement the same protocol they shoudl have a common command set that they both understand. OTOH, the MA may not implement all the measurement methods that Controller wnats it to execute, but that is a different matter. I guess the bottom line is that we may have different assumptions on the number of protocols lmap will define/reccomend, maybe? Regards, marcelo > I fully expect that whatever IETF protocols LMAP chooses to recommend > (that meet the criteria) will have a very specific and extremely > well-defined command set. So any provider who wants to use that > recommended protocol should be able to expect a certain degree of > interoperability. Though, in my experience, if there is no > certification program or test tools to ensure compliance with that > protocol’s specification, the provider may still need to put in a fair > amount of effort and testing to ensure a satisfactory degree of > interoperability between their procured MAs and Controller (assuming > they come from different vendors -- single vendor selection tends to > require less testing). The provider will probably take into account > how knowledgeable and experienced their own test labs are with the > protocol they select for use between their MAs and Controllers. > Likewise, 3^rd parties will make selections based on what makes sense > for them. > > Barbara > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From trammell@tik.ee.ethz.ch Tue Sep 17 23:21:15 2013 Return-Path: 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 0E1F311E8129 for ; Tue, 17 Sep 2013 23:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bCRsdoj8JOqW for ; Tue, 17 Sep 2013 23:21:10 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0E80811E8125 for ; Tue, 17 Sep 2013 23:21:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D18B3D930B; Wed, 18 Sep 2013 08:21:04 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BnWTJ89sO9Uk; Wed, 18 Sep 2013 08:21:04 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 7A2EBD9309; Wed, 18 Sep 2013 08:21:04 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_52949F50-5559-47F4-8244-B88F1622FFE5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <52393F16.3090904@it.uc3m.es> Date: Wed, 18 Sep 2013 08:21:03 +0200 Message-Id: <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1508) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 06:21:15 -0000 --Apple-Mail=_52949F50-5559-47F4-8244-B88F1622FFE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Marcelo, all, We should also consider that there's direct interoperability, and = conceptual interoperability. Direct interoperability: same wire protocol, same representation of the = same information model. You plug two devices in, point them at each = other or use the built-in discovery mechanism (if the protocol has one, = which LMAP doesn't), and they Just Work, if we and the implementors have = done their jobs right. Conceptual interoperability: different wire protocols, different = representations of two information models _largely derived_ from a = common base information model. Here, devices using different protocols = do not interoperate in terms of you plug them in and they talk to each = other. But if you're really talking about different access technologies = with completely different management stacks, interoperability in this = sense doesn't make sense -- you can't even plug a cable modem into a DSL = line, unless you're more creative (and more na=EFve) with physical layer = adaptation than you should be. :) But the common base information model (for the control protocol) here = does have advantages. One, people who understand LMAP/DOCSIS build = skills that transfer to LMAP/DSL or LMAP/LTE or what have you, because = all the protocol data elements have the same names and the same meanings = (and to the extent possible, the same encodings), = access-technology-specific information elements notwithstanding. = Conceptual interoperability also allows the easy design and = implementation of post-LMAP control and analysis consoles that hide most = of the specifics from the operator.=20 And in case there really is a need for a controller to cross access = technology boundaries (say, a cable network operator purchases a CLEC = and decides to maintain the DSL network separately while unifying = measurement), then conceptual interoperability allows lightweight = protocol proxies to be built that translate control across that = boundary.=20 So you can have a common command set, and common control terminology, = even if it's represented and transported differently, and get = significant interoperability benefits even if you aren't directly = interoperable. I'd say this approach is worth considering. Best regards, Brian On Sep 18, 2013, at 7:50 AM, marcelo bagnulo braun = wrote: > El 17/09/13 21:04, STARK, BARBARA H escribi=F3: >>=20 >> Mike said: >>=20 >> I=92m hoping the group assumes Interoperability as a significantly = high priority here. >>=20 >> If we ever hope to have a DSL modem, or Cable modem, wireless phone, = =85. To be delivered with MA capabilities it really must have a standard = command set or we=92ll end up with code variants that inhibit interop. >>=20 >> So I=92m leaning to a common command set =96 I don=92t care what you = call it, but it needs to be standard across the board. >>=20 >> I disagree strongly. Certainly the Measurement Methods need to = be totally interoperable -- but definition of those comes from ippm. = That=92s not part of the =93command set=94 we=92re talking about. >>=20 >> I believe very strongly that there is absolutely no requirement for = the MAs procured by a DSL provider be controllable by the Controllers of = a Cable operator. Nor that a provider=92s wireless devices be = controllable by the same Controller as that provider=92s DSL modems. = This, for me, was one of the big reasons for scoping this effort to MA = and Controller belonging to the same domain/entity. Interoperability = that needs to be guaranteed across entities (such as the Measurement = Methods) requires the level of standardization you suggest. = Interoperability internal to an entity can be defined and ensured by = that entity. >>=20 >> The criteria regarding what makes for a good Control or Collector = protocol must not include a requirement that all protocols used for = these purposes have a common command set -- there is no justification I = can think of to be that prescriptive. A protocol that meets these = criteria should be expected to have a well-defined command set. But that = really should go without saying -- that=92s obvious. >>=20 >=20 > I think the key disagreement here is whether we believe lmap will = produce one or more control protocols. > If we produce more than one protocol, i agree it doesnt make sense for = a controller impelmenting protocol 1 to interoperate with a MA that = implements protocol 2. >=20 > But if both implement the same protocol they shoudl have a common = command set that they both understand. OTOH, the MA may not implement = all the measurement methods that Controller wnats it to execute, but = that is a different matter. >=20 > I guess the bottom line is that we may have different assumptions on = the number of protocols lmap will define/reccomend, maybe? >=20 > Regards, marcelo >=20 >=20 >=20 >> I fully expect that whatever IETF protocols LMAP chooses to recommend = (that meet the criteria) will have a very specific and extremely = well-defined command set. So any provider who wants to use that = recommended protocol should be able to expect a certain degree of = interoperability. Though, in my experience, if there is no certification = program or test tools to ensure compliance with that protocol=92s = specification, the provider may still need to put in a fair amount of = effort and testing to ensure a satisfactory degree of interoperability = between their procured MAs and Controller (assuming they come from = different vendors -- single vendor selection tends to require less = testing). The provider will probably take into account how knowledgeable = and experienced their own test labs are with the protocol they select = for use between their MAs and Controllers. Likewise, 3^rd parties will = make selections based on what makes sense for them. >>=20 >> Barbara >>=20 >>=20 >>=20 >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --Apple-Mail=_52949F50-5559-47F4-8244-B88F1622FFE5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSOUZPAAoJENt3nsOmbNJcAlMIALttWXrp5ccWyYNqXMDnqJx6 d3fA3DA3Zq402G7dEMpJCk8W88bnRAlOVTLAMhgWVC70b1YeXQalsMeV7aGhfKrP hxEofMBWFSK8quAC3Vw2tNpTnGexAOHvG0Ssca4ZRInuKL5gw7BTj+yZGw0YNlQi VZxGV6FdIeLGqB61zUn+VCslIvb6eK2BO5JwEcbNQk7I+LNDiowh0uLrMbQw9QV6 o0gkyjMAGngmb2duxKXKhfbbgxWMjNi8T3+nvp4NK5esl/PIKZdnV5QQBrHCH0Xl NF9V60dStylvcf4qerUTcPjGPcIyvMWJpFEgy022EaD4O9R/Ho/eqBFEwmnfcLs= =WLQl -----END PGP SIGNATURE----- --Apple-Mail=_52949F50-5559-47F4-8244-B88F1622FFE5-- From j.schoenwaelder@jacobs-university.de Wed Sep 18 00:26:18 2013 Return-Path: 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 9F78A11E80E0 for ; Wed, 18 Sep 2013 00:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 laXn8heRE++r for ; Wed, 18 Sep 2013 00:26:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 69EA311E81A5 for ; Wed, 18 Sep 2013 00:26:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCE6120BFB; Wed, 18 Sep 2013 09:26:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rmkjJJChRelp; Wed, 18 Sep 2013 09:26:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23F1120BC1; Wed, 18 Sep 2013 09:26:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 270232867396; Wed, 18 Sep 2013 09:26:00 +0200 (CEST) Date: Wed, 18 Sep 2013 09:26:00 +0200 From: Juergen Schoenwaelder To: Brian Trammell Message-ID: <20130918072600.GA46326@elstar.local> Mail-Followup-To: Brian Trammell , marcelo bagnulo braun , lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcelo bagnulo braun , lmap@ietf.org Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 07:26:18 -0000 On Wed, Sep 18, 2013 at 08:21:03AM +0200, Brian Trammell wrote: > hi Marcelo, all, > > We should also consider that there's direct interoperability, and conceptual interoperability. > > Direct interoperability: same wire protocol, same representation of the same information model. You plug two devices in, point them at each other or use the built-in discovery mechanism (if the protocol has one, which LMAP doesn't), and they Just Work, if we and the implementors have done their jobs right. > > Conceptual interoperability: different wire protocols, different representations of two information models _largely derived_ from a common base information model. Here, devices using different protocols do not interoperate in terms of you plug them in and they talk to each other. But if you're really talking about different access technologies with completely different management stacks, interoperability in this sense doesn't make sense -- you can't even plug a cable modem into a DSL line, unless you're more creative (and more naïve) with physical layer adaptation than you should be. :) > Frankly, for IP-layer and above measurements (this is what IPPM is all about if I am not wrong), I fail to see why MAs would benefit from being access technology specific. Obviously, MAs such as Ripe Atlas probes or Sam Knows probes work on any access technology. The same happens to be tru for pure software probes users run in Web browsers or as apps. If we want to get LMAP MAs embedded into CPE devices, then in at least some parts of the world, the CPE devices are owned by the users and not the ISPs and they are pretty much access technology independent (e.g. I have a cable model sitting in front of my CPE/NAT router, for DSL lines you usually but a CPE/NAT router that does the DSL stuff as well here in Germany but you can still use it behind the Cable modem). I do see that there is a need to align the bootstrapping to whatever the access technology typically does. The IETF is usually about wire interoperability and the simple reason is that an open standard allows to create a market around it which has typically benefits for many stakeholders involved. I like to understand why this does not apply to LMAP in general. In other words, some of the use case should explain clearly why on the wire interoperability is a non-achievable goal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Wed Sep 18 02:50:40 2013 Return-Path: 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 ACEAC11E81C1 for ; Wed, 18 Sep 2013 02:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uUft6oehGPM8 for ; Wed, 18 Sep 2013 02:50:36 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id D428611E8226 for ; Wed, 18 Sep 2013 02:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16564; q=dns/txt; s=iport; t=1379497832; x=1380707432; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=l5tSCklx1PKtyyYLveKjTyDO2vDgEzru9x46Hq2vVEU=; b=dex/u9GLtGcYJb2Rfu76UiMHnixrU4p9D1lWVrfRWlrwaMDcM/CHrb63 t1RcIoJPITGL+5KAs/YEwiZAb8SDfNNvrYARh+Eu/UrX3lQBXNbT4vf1U y9+YP36eKbZNw4bxYU3thwUabf5MUxWVJCQOKCt1RSg0sPPbKQjSPXe0Q s=; X-Files: Attached Message Part : 133 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4FAOd1OVKQ/khR/2dsb2JhbABagwc4iVm3WUqBGBZtB4IlAQEBBAEBARVWCg0EHAMBAgEJFg8JAwIBAgEVJgIIBg0GAgEBh38MuWWOLoEoGAaEGAOQJoEvhiaBL4UBi0SDJjqBNQ X-IronPort-AV: E=Sophos;i="4.90,929,1371081600"; d="scan'208,217";a="18097999" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 18 Sep 2013 09:50:31 +0000 Received: from [10.61.105.61] (dhcp-10-61-105-61.cisco.com [10.61.105.61]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8I9oRY3027317 for ; Wed, 18 Sep 2013 09:50:27 GMT Message-ID: <52396883.2080905@cisco.com> Date: Wed, 18 Sep 2013 10:46:59 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "lmap@ietf.org" References: <523771FD.3000801@cisco.com> In-Reply-To: <523771FD.3000801@cisco.com> X-Forwarded-Message-Id: <523771FD.3000801@cisco.com> Content-Type: multipart/mixed; boundary="------------030300070504040406090509" Subject: [lmap] Fwd: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 09:50:40 -0000 This is a multi-part message in MIME format. --------------030300070504040406090509 Content-Type: multipart/alternative; boundary="------------050805030408050402060206" --------------050805030408050402060206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, FYI. Some LMAP related comments on the mailing list. Regards, Benoit -------- Original Message -------- Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers Date: Mon, 16 Sep 2013 23:02:53 +0200 From: Benoit Claise To: Stephen Farrell CC: , Brian Trammell On 15/09/2013 22:08, Stephen Farrell wrote: > Hi Brian, > > On 09/15/2013 08:42 PM, Brian Trammell wrote: >> hi Stephen, Benoit, all, >> >> The survey of anonymization techniques in 6235 was intended primarily >> to be a complete accounting of methods one _could_ use to anonymize >> fields (Information Elements) in a record, as opposed to a survey of >> methods we knew to be implemented. Here the idea was to allow a >> complete specification of a metadata format for specifying how >> records were anonymized, as input to future analysis tasks to be done >> on the data (since the anonymization method affects the set of >> analyses for which the data can be used). >> >> So we were really trying to solve a different problem: applying >> anonymization (to mask irrelevant and potentially privacy-sensitive >> information) while still maintaining the usefulness of the data for >> specific analytical tasks. Here we'd like to get rid of absolutely >> _everything_ that might be useful for analysis, just keeping around >> the minimum necessary for the operation and management of the >> protocol. >> >> Which gets me back to thinking it would be very useful to have a >> survey of the information radiated by protocols in common usage, then >> a systematic exercise to make sure each of those bits of information >> which may be identifiable serves a purpose that couldn't be done in >> an anonymous or pseudonymous way. > A fine research proposal. (Really, I'd try get dosh for that:-) > > But in an IETF context, maybe that'd be a thing that the lmap > wg [1] could look at? Anyone on this list active there? > > The lmap charter says: "The LMAP WG will consider privacy as a core > requirement and will ensure that by default measurement and collection > mechanisms and protocols standardized operate in a privacy-sensitive > manner, for example, ensuring that measurements are not personally > identifying except where permission for such has been granted by > identified subjects. Note that this does not mean that all uses of LMAP > need to turn on all privacy features but it does mean that privacy > features do need to be at least well-defined." > > (However, if I recall correctly I got that sentence shoe-horned into > their charter, so its not clear to me if the active participants are > actually keen on it or if it'll turn out to be RFC6919 fodder;-) The issue is that it depends on the use case. In the use case of the ISP monitoring my access device & link, the ISP has got anyway some personally identifiable information (PII) for his monitoring. And this is what I'm expecting as a customer .... when I call them, complaining about _my _link quality. However, in the regulator use case, monitoring my access link, I don't want to share any PII. Regards, Benoit > S. > > [1]http://datatracker.ietf.org/wg/lmap/charter/ > >> Cheers, >> >> Brian >> >> On Sep 15, 2013, at 7:44 PM, Stephen Farrell >> wrote: >> >>> Hi Benoit, >>> >>> On 09/14/2013 12:02 PM, Benoit Claise wrote: >>>> On 13/09/2013 14:37, Stephen Farrell wrote: >>>>> On 09/13/2013 05:54 AM, Moritz Bartl wrote: >>>>>> Hi, >>>>>> >>>>>> I would very much like to see servers having a minimal >>>>>> logging policy by default, especially and at least when it >>>>>> comes to IP addresses. I wonder if RFC 6302 is the right >>>>>> document to look at or extend for this. >>>>> Or obsolete it. >>>>> >>>>>> It is easy to flip a switch to enable IP logging. The default >>>>>> should be no IP logs, which is true for most XMPP servers, >>>>>> for example, but not for web or mail servers. >>>>> The wonderfully ironically named PRISM [1] project was an EU >>>>> funded project that did some work on obfuscating IP addresses >>>>> in logs. >>>> rfc6235 >>> Yep, sections 4 & 5 of that are generic and not really ipfix >>> specific. >>> >>> Do you know of implementations of that for ipfix? Or libraries that >>> do the various functions? >>> >>> I wonder if separating those sections out into a separate RFC would >>> result in more people writing code that supports those kinds of >>> transformations. Not sure to be honest. >>> >>> But that is a useful reference, regardless, Thanks, S. >>> >>>> Regards, Benoit >>>>> I'd love to see an RFC that described such techniques and >>>>> recommended when to use what, so we could point people at >>>>> that. >>>>> >>>>> Any takers for a -00 to get that going? >>>>> >>>>> S. >>>>> >>>>> [1]http://www.fp7-prism.eu/ >>>>> >>>>>> On a side node, can we do anything to get rid of sender IP >>>>>> addresses in (the first) Received headers of mail? >>>>>> >>>>>> -- Moritz _______________________________________________ >>>>>> perpass mailing listperpass@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/perpass >>>>>> >>>>> _______________________________________________ perpass mailing >>>>> listperpass@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/perpass . >>>>> >>> _______________________________________________ perpass mailing >>> listperpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >> >> _______________________________________________ perpass mailing list >> perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass >> > . > --------------050805030408050402060206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

FYI. Some LMAP related comments on the <perpass@ietf.org> mailing list.

Regards, Benoit

-------- Original Message --------
Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers
Date: Mon, 16 Sep 2013 23:02:53 +0200
From: Benoit Claise <bclaise@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
CC: <perpass@ietf.org>, Brian Trammell <trammell@tik.ee.ethz.ch>


On 15/09/2013 22:08, Stephen Farrell wrote:
Hi Brian,

On 09/15/2013 08:42 PM, Brian Trammell wrote:

hi Stephen, Benoit, all,

The survey of anonymization techniques in 6235 was intended primarily
to be a complete accounting of methods one _could_ use to anonymize
fields (Information Elements) in a record, as opposed to a survey of
methods we knew to be implemented. Here the idea was to allow a
complete specification of a metadata format for specifying how
records were anonymized, as input to future analysis tasks to be done
on the data (since the anonymization method affects the set of
analyses for which the data can be used).

So we were really trying to solve a different problem: applying
anonymization (to mask irrelevant and potentially privacy-sensitive
information) while still maintaining the usefulness of the data for
specific analytical tasks. Here we'd like to get rid of absolutely
_everything_ that might be useful for analysis, just keeping around
the minimum necessary for the operation and management of the
protocol.

Which gets me back to thinking it would be very useful to have a
survey of the information radiated by protocols in common usage, then
a systematic exercise to make sure each of those bits of information
which may be identifiable serves a purpose that couldn't be done in
an anonymous or pseudonymous way.

A fine research proposal. (Really, I'd try get dosh for that:-)

But in an IETF context, maybe that'd be a thing that the lmap
wg [1] could look at? Anyone on this list active there?

The lmap charter says: "The LMAP WG will consider privacy as a core
requirement and will ensure that by default measurement and collection
mechanisms and protocols standardized operate in a privacy-sensitive
manner, for example, ensuring that measurements are not personally
identifying except where permission for such has been granted by
identified subjects. Note that this does not mean that all uses of LMAP
need to turn on all privacy features but it does mean that privacy
features do need to be at least well-defined."

(However, if I recall correctly I got that sentence shoe-horned into
their charter, so its not clear to me if the active participants are
actually keen on it or if it'll turn out to be RFC6919 fodder;-)
The issue is that it depends on the use case.
In the use case of the ISP monitoring my access device & link, the ISP has got anyway some personally identifiable information (PII) for his monitoring. And this is what I'm expecting as a customer .... when I call them, complaining about my link quality.
However, in the regulator use case, monitoring my access link, I don't want to share any PII.

Regards, Benoit
S.

[1] http://datatracker.ietf.org/wg/lmap/charter/


Cheers,

Brian

On Sep 15, 2013, at 7:44 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:


Hi Benoit,

On 09/14/2013 12:02 PM, Benoit Claise wrote:

On 13/09/2013 14:37, Stephen Farrell wrote:

On 09/13/2013 05:54 AM, Moritz Bartl wrote:

Hi,

I would very much like to see servers having a minimal
logging policy by default, especially and at least when it
comes to IP addresses. I wonder if RFC 6302 is the right
document to look at or extend for this.

Or obsolete it.


It is easy to flip a switch to enable IP logging. The default
should be no IP logs, which is true for most XMPP servers,
for example, but not for web or mail servers.

The wonderfully ironically named PRISM [1] project was an EU
funded project that did some work on obfuscating IP addresses
in logs.

rfc6235

Yep, sections 4 & 5 of that are generic and not really ipfix 
specific.

Do you know of implementations of that for ipfix? Or libraries that
do the various functions?

I wonder if separating those sections out into a separate RFC would
result in more people writing code that supports those kinds of
transformations. Not sure to be honest.

But that is a useful reference, regardless, Thanks, S.


Regards, Benoit

I'd love to see an RFC that described such techniques and
recommended when to use what, so we could point people at
that.

Any takers for a -00 to get that going?

S.

[1] http://www.fp7-prism.eu/


On a side node, can we do anything to get rid of sender IP
addresses in (the first) Received headers of mail?

-- Moritz _______________________________________________ 
perpass mailing list perpass@ietf.org 
https://www.ietf.org/mailman/listinfo/perpass


_______________________________________________ perpass mailing
list perpass@ietf.org 
https://www.ietf.org/mailman/listinfo/perpass .



            

            
_______________________________________________ perpass mailing
list perpass@ietf.org 
https://www.ietf.org/mailman/listinfo/perpass


          

          

_______________________________________________ perpass mailing list 
perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass



        

        
.



      

      

      

    

    

  


--------------050805030408050402060206--

--------------030300070504040406090509
Content-Type: text/plain; charset=windows-1252;
 name="Attached Message Part"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message Part"

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass


--------------030300070504040406090509--

From bs7652@att.com  Wed Sep 18 06:33:13 2013
Return-Path: 
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 1855211E8289 for ; Wed, 18 Sep 2013 06:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.739
X-Spam-Level: 
X-Spam-Status: No, score=-6.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 lVy0taBeKqah for ; Wed, 18 Sep 2013 06:33:06 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id C807811E811E for ; Wed, 18 Sep 2013 06:33:05 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 19ba9325.0.995673.00-468.2735603.nbfkord-smmo07.seg.att.com (envelope-from );  Wed, 18 Sep 2013 13:33:06 +0000 (UTC)
X-MXL-Hash: 5239ab9233d09191-08a97b7a1553f8962e3bc587bb3ad5323b7eaea4
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8IDX4s2009647; Wed, 18 Sep 2013 09:33:05 -0400
Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8IDWvnZ009566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Sep 2013 09:33:02 -0400
Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 18 Sep 2013 13:32:34 GMT
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0158.001; Wed, 18 Sep 2013 09:32:34 -0400
From: "STARK, BARBARA H" 
To: marcelo bagnulo braun , "lmap@ietf.org" 
Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
Thread-Index: Ac6vy8pkBhhbxrNjQtSjdrst4mkRYAABypiwAO4OjXAAB4wzsAAD0AhwAAAihGAAAgLhkAAB2+XAAAIQbgAAIOSMAAAFrWzg
Date: Wed, 18 Sep 2013 13:32:33 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E611303720AC@GAALPA1MSGUSR9L.ITServices.sbc.com>
References:  <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com>  <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com>  <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es>
In-Reply-To: <52393F16.3090904@it.uc3m.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.91.49]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
X-AnalysisOut: [v=2.0 cv=O8iOSmBW c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=yCurQ6xIU-YA:10 a=l4EBnxoveaQA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=Lb5Mp4LI0xsA:10 a=S3kf2H8kst529r67ouAA:9 a=CjuIK1]
X-AnalysisOut: [q_8ugA:10]
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 13:33:13 -0000

> I think the key disagreement here is whether we believe lmap will produce
> one or more control protocols.

 I am hoping lmap doesn't actually "produce" any protocols. But based on th=
e charter and charter discussions, I'm fully expecting lmap to "select/exte=
nd" exactly one IETF-defined protocol as a Control protocol and exactly one=
 as a Report protocol. What I want, is to make sure that lmap doesn't const=
rain its RFCs and recommendations in a manner that fails to recognize that =
other SDOs/SIGs will make other protocol recommendations, and entities will=
 be free to choose which of these recommendations to use.

We have been discussing the framework draft and what is to be said about th=
ese 2 protocols in the framework draft. At the level of the framework draft=
, I would like to see text that describes the necessary and desirable funct=
ionality of a good Control/Report protocol. I am opposed to text that pre-s=
upposes a particular Control or Report protocol, or to text that fails to r=
ecognize that other SDOs/SIGs will also make protocol recommendations. I wo=
uld like the *framework* guidance in this area to be useful as input to all=
 other orgs who want to select/extend a protocol for these purposes.

This does not prevent lmap from doing its own selection/extension of exactl=
y one protocol for each purpose.
This is about having the framework draft not characterize its expectations =
of a Control or Report protocol in such a way as to ensure that only the IE=
TF's selected/extended protocols can ever meet those expectations.
Barbara


From marcelo@it.uc3m.es  Wed Sep 18 06:43:45 2013
Return-Path: 
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 5257F11E82E6 for ; Wed, 18 Sep 2013 06:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.656
X-Spam-Level: 
X-Spam-Status: No, score=-106.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 UJXA2TVYI8Io for ; Wed, 18 Sep 2013 06:43:40 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8716A11E8287 for ; Wed, 18 Sep 2013 06:43:40 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id ED314894A63 for ; Wed, 18 Sep 2013 15:43:38 +0200 (CEST)
X-uc3m-safe: yes
Received: from dummyhost21.it.uc3m.es (unknown [163.117.139.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id E0F0C767376 for ; Wed, 18 Sep 2013 15:43:38 +0200 (CEST)
Message-ID: <5239AE0A.9050200@it.uc3m.es>
Date: Wed, 18 Sep 2013 15:43:38 +0200
From: marcelo bagnulo braun 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: lmap@ietf.org
References:  <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com>  <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com>  <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <2D09D61DDFA73D4C884805CC7865E611303720AC@GAALPA1MSGUSR9L.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303720AC@GAALPA1MSGUSR9L.ITServices.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Wed, 18 Sep 2013 15:43:38 +0200 (CEST)
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20158.004
X-TM-AS-Result: No--18.105-7.0-31-1
X-imss-scan-details: No--18.105-7.0-31-1
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 13:43:45 -0000

I think i agree with what you said.


El 18/09/13 15:32, STARK, BARBARA H escribió:
>> I think the key disagreement here is whether we believe lmap will produce
>> one or more control protocols.
>   I am hoping lmap doesn't actually "produce" any protocols. But based on the charter and charter discussions, I'm fully expecting lmap to "select/extend" exactly one IETF-defined protocol as a Control protocol and exactly one as a Report protocol. What I want, is to make sure that lmap doesn't constrain its RFCs and recommendations in a manner that fails to recognize that other SDOs/SIGs will make other protocol recommendations, and entities will be free to choose which of these recommendations to use.
>
> We have been discussing the framework draft and what is to be said about these 2 protocols in the framework draft. At the level of the framework draft, I would like to see text that describes the necessary and desirable functionality of a good Control/Report protocol. I am opposed to text that pre-supposes a particular Control or Report protocol, or to text that fails to recognize that other SDOs/SIGs will also make protocol recommendations. I would like the *framework* guidance in this area to be useful as input to all other orgs who want to select/extend a protocol for these purposes.
>
> This does not prevent lmap from doing its own selection/extension of exactly one protocol for each purpose.
> This is about having the framework draft not characterize its expectations of a Control or Report protocol in such a way as to ensure that only the IETF's selected/extended protocols can ever meet those expectations.
> Barbara
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap
>


From bs7652@att.com  Wed Sep 18 07:23:02 2013
Return-Path: 
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 26B4A11E82FD for ; Wed, 18 Sep 2013 07:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.715
X-Spam-Level: 
X-Spam-Status: No, score=-6.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 IsCirV+Yj+WT for ; Wed, 18 Sep 2013 07:22:55 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC7E11E811E for ; Wed, 18 Sep 2013 07:22:53 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id d37b9325.0.2534077.00-238.6989629.nbfkord-smmo06.seg.att.com (envelope-from );  Wed, 18 Sep 2013 14:22:55 +0000 (UTC)
X-MXL-Hash: 5239b73f3d484037-3bb7ea116cd6ff5614f0ad87734b2b7504b92dc3
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8IEMq3j028263; Wed, 18 Sep 2013 10:22:53 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8IEMavw028083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Sep 2013 10:22:45 -0400
Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 18 Sep 2013 14:22:24 GMT
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0158.001; Wed, 18 Sep 2013 10:22:24 -0400
From: "STARK, BARBARA H" 
To: Juergen Schoenwaelder , "Brian Trammell" 
Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
Thread-Index: AQHOtEBmosHnAD2uTEyRx3kEALw3KJnLcBFg
Date: Wed, 18 Sep 2013 14:22:20 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com>  <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com>  <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> <20130918072600.GA46326@elstar.local>
In-Reply-To: <20130918072600.GA46326@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.91.49]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
X-AnalysisOut: [v=2.0 cv=WrCcx6jv c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=yCurQ6xIU-YA:10 a=l4EBnxoveaQA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=Lb5Mp4LI0xsA:10 a=qmukfT2wkOEIzUuwbcsA:9 a=CjuIK1]
X-AnalysisOut: [q_8ugA:10]
Cc: marcelo bagnulo braun , "lmap@ietf.org" 
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 14:23:02 -0000

> Frankly, for IP-layer and above measurements (this is what IPPM is all ab=
out
> if I am not wrong), I fail to see why MAs would benefit from being access
> technology specific. Obviously, MAs such as Ripe Atlas probes or Sam Know=
s
> probes work on any access technology. The same happens to be tru for pure
> software probes users run in Web browsers or as apps. If we want to get
> LMAP MAs embedded into CPE devices, then in at least some parts of the
> world, the CPE devices are owned by the users and not the ISPs and they a=
re
> pretty much access technology independent (e.g. I have a cable model sitt=
ing
> in front of my CPE/NAT router, for DSL lines you usually but a CPE/NAT ro=
uter
> that does the DSL stuff as well here in Germany but you can still use it =
behind
> the Cable modem). I do see that there is a need to align the bootstrappin=
g to
> whatever the access technology typically does.
>=20
> The IETF is usually about wire interoperability and the simple reason is =
that an
> open standard allows to create a market around it which has typically
> benefits for many stakeholders involved. I like to understand why this do=
es
> not apply to LMAP in general. In other words, some of the use case should
> explain clearly why on the wire interoperability is a non-achievable goal=
.

I believe that it is important that lmap-defined MAs be able to operate use=
fully in the broader ecosystem of MAs that also perform Measurement Methods=
 at physical and link layers, and other "custom" Measurement Methods.

The lmap framework must not restrict or assume that all Measurement Methods=
 that an MA supports are defined by ippm, defined by IETF, or that they are=
 necessarily intended for use by end users or regulators or will be provide=
d or useful to any other entity (than the one in charge of the MA). If the =
framework is written in such a way as to restrict lmap-defined MAs to only =
ever be used for ippm metrics, then that's a pretty useless framework, IMO.=
 Many operators will be unwilling to have both lmap MA and a separate layer=
 1/2 MA, on the same device, using separate Control and Report protocols. C=
ertainly, the lmap framework must not assume that all MAs are operated by s=
ervice providers. Likewise, it must not assume that they are not operated b=
y service providers. The framework needs to be sufficiently flexible to all=
ow for all of the use cases that are to be supported by it.

I have no desire for lmap to describe/define information or data models for=
 these other Measurement Methods. I do have a desire to ensure that the lma=
p *framework* recognizes that MAs will include these, and to ensure that th=
e *framework* recognizes this will occur and does not do anything to restri=
ct or preclude this.=20
Barbara

=20

From acmorton@att.com  Wed Sep 18 08:37:13 2013
Return-Path: 
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 8BCCC11E8241 for ; Wed, 18 Sep 2013 08:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.738
X-Spam-Level: 
X-Spam-Status: No, score=-106.738 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 wK2ePFnmpW3j for ; Wed, 18 Sep 2013 08:37:08 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4370C11E8160 for ; Wed, 18 Sep 2013 08:36:54 -0700 (PDT)
Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 49B9C1204A6; Wed, 18 Sep 2013 11:36:49 -0400 (EDT)
Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-azure.research.att.com (Postfix) with ESMTP id 0B800E267A; Wed, 18 Sep 2013 11:36:51 -0400 (EDT)
Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Wed, 18 Sep 2013 11:36:50 -0400
From: "MORTON, ALFRED C (AL)" 
To: Benoit Claise , "lmap@ietf.org" , "stephen.farrell@cs.tcd.ie" 
Date: Wed, 18 Sep 2013 11:36:50 -0400
Thread-Topic: [lmap] Fwd: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers
Thread-Index: Ac60VJAEBXRAQB7GT6SyeEE/Z4LH6QAL9tYQ
Message-ID: <2845723087023D4CB5114223779FA9C8AAC21C61@njfpsrvexg8.research.att.com>
References: <523771FD.3000801@cisco.com> <52396883.2080905@cisco.com>
In-Reply-To: <52396883.2080905@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8AAC21C61njfpsrvexg8rese_"
MIME-Version: 1.0
Subject: Re: [lmap] Fwd: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 15:37:13 -0000

--_000_2845723087023D4CB5114223779FA9C8AAC21C61njfpsrvexg8rese_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Benoit and Stephen,
watch for the next lmap framework draft,
it will be non-compliant with RFC6919.
Al

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Ben=
oit Claise
Sent: Wednesday, September 18, 2013 4:47 AM
To: lmap@ietf.org
Subject: [lmap] Fwd: Re: [perpass] RFC 6302 Logging Recommendations for Int=
ernet-Facing Servers

Dear all,

FYI. Some LMAP related comments on the  mailing list.

Regards, Benoit

-------- Original Message --------
Subject:

Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers

Date:

Mon, 16 Sep 2013 23:02:53 +0200

From:

Benoit Claise 

To:

Stephen Farrell 

CC:

, Brian Trammell 


On 15/09/2013 22:08, Stephen Farrell wrote:

Hi Brian,



On 09/15/2013 08:42 PM, Brian Trammell wrote:

hi Stephen, Benoit, all,



The survey of anonymization techniques in 6235 was intended primarily

to be a complete accounting of methods one _could_ use to anonymize

fields (Information Elements) in a record, as opposed to a survey of

methods we knew to be implemented. Here the idea was to allow a

complete specification of a metadata format for specifying how

records were anonymized, as input to future analysis tasks to be done

on the data (since the anonymization method affects the set of

analyses for which the data can be used).



So we were really trying to solve a different problem: applying

anonymization (to mask irrelevant and potentially privacy-sensitive

information) while still maintaining the usefulness of the data for

specific analytical tasks. Here we'd like to get rid of absolutely

_everything_ that might be useful for analysis, just keeping around

the minimum necessary for the operation and management of the

protocol.



Which gets me back to thinking it would be very useful to have a

survey of the information radiated by protocols in common usage, then

a systematic exercise to make sure each of those bits of information

which may be identifiable serves a purpose that couldn't be done in

an anonymous or pseudonymous way.

A fine research proposal. (Really, I'd try get dosh for that:-)



But in an IETF context, maybe that'd be a thing that the lmap

wg [1] could look at? Anyone on this list active there?



The lmap charter says: "The LMAP WG will consider privacy as a core

requirement and will ensure that by default measurement and collection

mechanisms and protocols standardized operate in a privacy-sensitive

manner, for example, ensuring that measurements are not personally

identifying except where permission for such has been granted by

identified subjects. Note that this does not mean that all uses of LMAP

need to turn on all privacy features but it does mean that privacy

features do need to be at least well-defined."



(However, if I recall correctly I got that sentence shoe-horned into

their charter, so its not clear to me if the active participants are

actually keen on it or if it'll turn out to be RFC6919 fodder;-)
The issue is that it depends on the use case.
In the use case of the ISP monitoring my access device & link, the ISP has =
got anyway some personally identifiable information (PII) for his monitorin=
g. And this is what I'm expecting as a customer .... when I call them, comp=
laining about my link quality.
However, in the regulator use case, monitoring my access link, I don't want=
 to share any PII.

Regards, Benoit




S.



[1] http://datatracker.ietf.org/wg/lmap/charter/



Cheers,



Brian



On Sep 15, 2013, at 7:44 PM, Stephen Farrell

 wrote:



Hi Benoit,



On 09/14/2013 12:02 PM, Benoit Claise wrote:

On 13/09/2013 14:37, Stephen Farrell wrote:

On 09/13/2013 05:54 AM, Moritz Bartl wrote:

Hi,



I would very much like to see servers having a minimal

logging policy by default, especially and at least when it

comes to IP addresses. I wonder if RFC 6302 is the right

document to look at or extend for this.

Or obsolete it.



It is easy to flip a switch to enable IP logging. The default

should be no IP logs, which is true for most XMPP servers,

for example, but not for web or mail servers.

The wonderfully ironically named PRISM [1] project was an EU

funded project that did some work on obfuscating IP addresses

in logs.

rfc6235

Yep, sections 4 & 5 of that are generic and not really ipfix

specific.



Do you know of implementations of that for ipfix? Or libraries that

do the various functions?



I wonder if separating those sections out into a separate RFC would

result in more people writing code that supports those kinds of

transformations. Not sure to be honest.



But that is a useful reference, regardless, Thanks, S.



Regards, Benoit

I'd love to see an RFC that described such techniques and

recommended when to use what, so we could point people at

that.



Any takers for a -00 to get that going?



S.



[1] http://www.fp7-prism.eu/



On a side node, can we do anything to get rid of sender IP

addresses in (the first) Received headers of mail?



-- Moritz _______________________________________________

perpass mailing list perpass@ietf.org

https://www.ietf.org/mailman/listinfo/perpass



_______________________________________________ perpass mailing

list perpass@ietf.org

https://www.ietf.org/mailman/listinfo/perpass .





_______________________________________________ perpass mailing

list perpass@ietf.org

https://www.ietf.org/mailman/listinfo/perpass





_______________________________________________ perpass mailing list

perpass@ietf.org https://www.ietf.org/mailman/list=
info/perpass



.





--_000_2845723087023D4CB5114223779FA9C8AAC21C61njfpsrvexg8rese_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
Benoit and Stephen,
watch for =
the next lmap framework draft, 
<=
span style=3D'font-size:10.0pt;font-family:"Courier New";color:windowtext'>=
it will be non-compliant with RFC6919.
Al
 
From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behal=
f Of Benoit Claise
Sent: Wednesday, September 18, 2013 4:47 A=
M
To: lmap@ietf.org
Subject: [lmap] Fwd: Re: [perpass] =
RFC 6302 Logging Recommendations for Internet-Facing Servers
 
Dear all,

FYI. Some LMAP related comments on the <perpass@ietf.org> mailing list.

Regards, Benoit

-------- Origina=
l Message -------- 
=

Subject: 
Re: [perpass] RFC 6302 Logging Recommendations fo=
r Internet-Facing Servers
Date: 
Mon, 16 Sep 2013 23:02:53 +0200
F=
rom: 
Benoit Claise <bclaise=
@cisco.com>
To: 
Stephen Farrell <stephen.farrell@cs.tcd.ie>
CC: 
<perpass@ietf.org>, Brian Trammell =
<trammell@tik.ee.ethz.ch><=
/a>
 
On 15/09/2013 2=
2:08, Stephen Farrell wrote:
Hi Brian,
&=
nbsp;
On 09/15/2013 08:42 PM, Brian Trammell wrote:
hi=
 Stephen, Benoit, all,
 
The=
 survey of anonymization techniques in 6235 was intended primarily
to be a complete accounting of methods one _could_ use to anon=
ymize
fields (Information Elements) in a record, as op=
posed to a survey of
methods we knew to be implemented=
. Here the idea was to allow a
complete specification =
of a metadata format for specifying how
records were a=
nonymized, as input to future analysis tasks to be done
on the data (since the anonymization method affects the set of=

analyses for which the data can be used).
<=
o:p> 
So we were really trying to solve a different pr=
oblem: applying
anonymization (to mask irrelevant and =
potentially privacy-sensitive
information) while still=
 maintaining the usefulness of the data for
specific a=
nalytical tasks. Here we'd like to get rid of absolutely
_everything_ that might be useful for analysis, just keeping around=

the minimum necessary for the operation and management of =
the
protocol.
 
Which gets me back to thinking it would be very useful to have a
survey of the information radiated by protocols in comm=
on usage, then
a systematic exercise to make sure each=
 of those bits of information
which may be identifiabl=
e serves a purpose that couldn't be done in
an anonymo=
us or pseudonymous way.
A fine research p=
roposal. (Really, I'd try get dosh for that:-)
&n=
bsp;
But in an IETF context, maybe that'd be a thing that t=
he lmap
wg [1] could look at? Anyone on this list acti=
ve there?
 
The lmap charter=
 says: "The LMAP WG will consider privacy as a core
requirement and will ensure that by default measurement and collection
mechanisms and protocols standardized operate in a priv=
acy-sensitive
manner, for example, ensuring that measu=
rements are not personally
identifying except where pe=
rmission for such has been granted by
identified subje=
cts. Note that this does not mean that all uses of LMAP
need to turn on all privacy features but it does mean that privacy
features do need to be at least well-defined."
 
(However, if I recall correctly I =
got that sentence shoe-horned into
their charter, so i=
ts not clear to me if the active participants are
actu=
ally keen on it or if it'll turn out to be RFC6919 fodder;-)
The issue is that it depends on the use=
 case.
In the use case of the ISP monitoring my access device & link=
, the ISP has got anyway some personally identifiable information (PII) for=
 his monitoring. And this is what I'm expecting as a customer .... when I c=
all them, complaining about my link quality.
However, in the regu=
lator use case, monitoring my access link, I don't want to share any PII.
Regards, Benoit

 
S.
 
[1] http://datatracker.ietf.org/wg/lmap=
/charter/
 
Cheers,
 
Brian
 
On Sep 15, 2013, at 7:44 PM, Stephen Farrell
=
<stephen.farrell@cs.tcd.ie&=
gt; wrote:
 
Hi Benoit,
=

 
On 09/14/2013 12:02 PM, Benoit Claise wrot=
e:
On 13/09/2013 14:37, Stephen Farrell wrote:
On 09/13/2013 05:5=
4 AM, Moritz Bartl wrote:
Hi,
 
I would very much like to see servers having a minimal<=
/pre>
logging policy by default, especially and at least when it
comes to IP addresses. I wonder if RFC 6302 is the right
document to look at or extend for this.
<=
/blockquote>
Or obsolete it.
 
It is eas=
y to flip a switch to enable IP logging. The default
s=
hould be no IP logs, which is true for most XMPP servers,
<=
pre>for example, but not for web or mail servers.
The wonderfully ironically named PRISM [1] project was an EU<=
/o:p>
funded project that did some work on obfuscating IP address=
es
in logs.
rfc6235<=
o:p>
Yep, sections 4 & 5 of that are gener=
ic and not really ipfix 
specific.
 
Do you know of implementations of that for ip=
fix? Or libraries that
do the various functions?<=
/o:p>
 
I wonder if separating those se=
ctions out into a separate RFC would
result in more pe=
ople writing code that supports those kinds of
transfo=
rmations. Not sure to be honest.
 
But that is a useful reference, regardless, Thanks, S.
 
Regards, Benoit
I'd love to see an RFC that descri=
bed such techniques and
recommended when to use what, =
so we could point people at
that.
 
Any takers for a -00 to get that going?
 
S.
&nb=
sp;
[1] http://www.fp7=
-prism.eu/
 
On a side node, can we do a=
nything to get rid of sender IP
addresses in (the firs=
t) Received headers of mail?
 
-- Moritz _______________________________________________ 
perpass mailing list perpass@ie=
tf.org 
https://www.ietf.org/mailman/listinfo/perpass
 
______________________=
_________________________ perpass mailing
list perpass@ietf.org 
https://www.ietf.org=
/mailman/listinfo/perpass .
 
 
_______________=
________________________________ perpass mailing
list =
perpass@ietf.org 
<=
pre>https://www.i=
etf.org/mailman/listinfo/perpass
 
 
_______________________=
________________________ perpass mailing list 
perpass@ietf.org https://www.ietf.org/mailman/listinfo/perp=
ass
 
.
 
 
&nbs=
p;
=

--_000_2845723087023D4CB5114223779FA9C8AAC21C61njfpsrvexg8rese_--

From aakhter@cisco.com  Wed Sep 18 19:01:17 2013
Return-Path: 
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 1CF6C11E816E for ; Wed, 18 Sep 2013 19:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 CGse2N0v6G8h for ; Wed, 18 Sep 2013 19:01:02 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F031A11E80D7 for ; Wed, 18 Sep 2013 19:01:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4530; q=dns/txt; s=iport; t=1379556062; x=1380765662; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=a/cQhZMVZI3uDtHXfDgaK73UfmXlcAUNAaVAP7VjHbg=; b=bYDh6jIG6qRtFY3JfsFecce9ZtJMkGi1dDH5AIqTDaTQKhibRHPA/ssv WxSN8iCA0PpIsihlo8xtUiy7I7JnZoa6yJmK4KrETwQdqxJNVc/r/SGsz a4jtO0isWVv3Fa64iFp4MYrqlDQiu3JCtAzyOyXNic+BGzpyYUhcG9ibI E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAIRZOlKtJV2a/2dsb2JhbABZgwc4UsEugSIWdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJBycLFAkIAgQBDQUIh3UGDLoxBI82MQcGgxiBAAOTXpYRgWaBPoIq
X-IronPort-AV: E=Sophos;i="4.90,934,1371081600"; d="scan'208";a="261642994"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 19 Sep 2013 02:01:01 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8J211Te029935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 02:01:01 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 21:01:01 -0500
From: "Aamer Akhter (aakhter)" 
To: "STARK, BARBARA H" , Juergen Schoenwaelder , "Brian	Trammell" 
Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
Thread-Index: AQHOtEBi6oEH6esQHE6hUMyDzSjsYJnL4EgAgABqi3A=
Date: Thu, 19 Sep 2013 02:01:00 +0000
Message-ID: <75C0E47A1889264493A2DCB2869AC09633571A9A@xmb-rcd-x15.cisco.com>
References: <2D09D61DDFA73D4C884805CC7865E6113036E14C@GAALPA1MSGUSR9L.ITServices.sbc.com>  <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com>  <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> <20130918072600.GA46326@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.150.43.120]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: marcelo bagnulo braun , "lmap@ietf.org" 
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 02:01:17 -0000

Inline with AA>=20

-----Original Message-----
From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STA=
RK, BARBARA H
Sent: Wednesday, September 18, 2013 10:22 AM
To: Juergen Schoenwaelder; Brian Trammell
Cc: marcelo bagnulo braun; lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M=
A and Controller

> Frankly, for IP-layer and above measurements (this is what IPPM is all=20
> about if I am not wrong), I fail to see why MAs would benefit from=20
> being access technology specific. Obviously, MAs such as Ripe Atlas=20
> probes or Sam Knows probes work on any access technology. The same=20
> happens to be tru for pure software probes users run in Web browsers=20
> or as apps. If we want to get LMAP MAs embedded into CPE devices, then=20
> in at least some parts of the world, the CPE devices are owned by the=20
> users and not the ISPs and they are pretty much access technology=20
> independent (e.g. I have a cable model sitting in front of my CPE/NAT=20
> router, for DSL lines you usually but a CPE/NAT router that does the=20
> DSL stuff as well here in Germany but you can still use it behind the=20
> Cable modem). I do see that there is a need to align the bootstrapping to=
 whatever the access technology typically does.
>=20
> The IETF is usually about wire interoperability and the simple reason=20
> is that an open standard allows to create a market around it which has=20
> typically benefits for many stakeholders involved. I like to=20
> understand why this does not apply to LMAP in general. In other words,=20
> some of the use case should explain clearly why on the wire interoperabil=
ity is a non-achievable goal.

I believe that it is important that lmap-defined MAs be able to operate use=
fully in the broader ecosystem of MAs that also perform Measurement Methods=
 at physical and link layers, and other "custom" Measurement Methods.

The lmap framework must not restrict or assume that all Measurement Methods=
 that an MA supports are defined by ippm, defined by IETF, or that they are=
 necessarily intended for use by end users or regulators or will be provide=
d or useful to any other entity (than the one in charge of the MA). If the =
framework is written in such a way as to restrict lmap-defined MAs to only =
ever be used for ippm metrics, then that's a pretty useless framework, IMO.=
 Many operators will be unwilling to have both lmap MA and a separate layer=
 1/2 MA, on the same device, using separate Control and Report protocols. C=
ertainly, the lmap framework must not assume that all MAs are operated by s=
ervice providers. Likewise, it must not assume that they are not operated b=
y service providers. The framework needs to be sufficiently flexible to all=
ow for all of the use cases that are to be supported by it.

I have no desire for lmap to describe/define information or data models for=
 these other Measurement Methods. I do have a desire to ensure that the lma=
p *framework* recognizes that MAs will include these, and to ensure that th=
e *framework* recognizes this will occur and does not do anything to restri=
ct or preclude this.=20

AA> I personally believe this is reasonable.

AA> Regarding metrics we've done similar things in IPFIX with the 'enterpri=
se' range of IEs. Given that the IETF probably doesn't have much interest i=
n defining RF channel reports in LMAP or the results of some DOCSIS test, i=
t does seem to make sense to include options for other industry registries.=
 Ie cablelabs etc. that would represent the lower layers. It does need to b=
e organized though.

AA> Regarding the control/report protocol-- also agree. While we may have a=
 recommended protocol  to start off with, the framework should be layered s=
uch that later on other protocols could be used instead. I do think of prot=
ocol Y has some compelling features (lower batter usage, is the standard ma=
nagement interface on cable modems, whatever) that usage should not be left=
 undefined but should be brought back to the LMAP WG.  That said, I fully e=
xpect proprietary LMAP control/report mechanisms to be implemented.  Ffor e=
xample, for over-the-top content providers. In my mind this is ok- parts of=
 the LMAP framework _should _be reusable. It's a good goal to have.=20


Barbara

=20
_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap

From j.schoenwaelder@jacobs-university.de  Thu Sep 19 00:26:52 2013
Return-Path: 
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 5698421F9BEF for ; Thu, 19 Sep 2013 00:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.133
X-Spam-Level: 
X-Spam-Status: No, score=-103.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 wtOhcGLZPuy9 for ; Thu, 19 Sep 2013 00:26:47 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EA16921F9BD8 for ; Thu, 19 Sep 2013 00:26:46 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0DEF20FEB; Thu, 19 Sep 2013 09:19:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JxFjYnpjMKuk; Thu, 19 Sep 2013 09:19:29 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAAC5214D0; Thu, 19 Sep 2013 09:07:34 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id EF0FF2868678; Thu, 19 Sep 2013 09:06:53 +0200 (CEST)
Date: Thu, 19 Sep 2013 09:06:53 +0200
From: Juergen Schoenwaelder 
To: "STARK, BARBARA H" 
Message-ID: <20130919070653.GA51566@elstar.local>
Mail-Followup-To: "STARK, BARBARA H" , Brian Trammell , marcelo bagnulo braun , "lmap@ietf.org" 
References: <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com>  <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> <20130918072600.GA46326@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: marcelo bagnulo braun , "lmap@ietf.org" , Brian Trammell 
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 07:26:52 -0000

On Wed, Sep 18, 2013 at 02:22:20PM +0000, STARK, BARBARA H wrote:
> > Frankly, for IP-layer and above measurements (this is what IPPM is all about
> > if I am not wrong), I fail to see why MAs would benefit from being access
> > technology specific. Obviously, MAs such as Ripe Atlas probes or Sam Knows
> > probes work on any access technology. The same happens to be tru for pure
> > software probes users run in Web browsers or as apps. If we want to get
> > LMAP MAs embedded into CPE devices, then in at least some parts of the
> > world, the CPE devices are owned by the users and not the ISPs and they are
> > pretty much access technology independent (e.g. I have a cable model sitting
> > in front of my CPE/NAT router, for DSL lines you usually but a CPE/NAT router
> > that does the DSL stuff as well here in Germany but you can still use it behind
> > the Cable modem). I do see that there is a need to align the bootstrapping to
> > whatever the access technology typically does.
> > 
> > The IETF is usually about wire interoperability and the simple reason is that an
> > open standard allows to create a market around it which has typically
> > benefits for many stakeholders involved. I like to understand why this does
> > not apply to LMAP in general. In other words, some of the use case should
> > explain clearly why on the wire interoperability is a non-achievable goal.
> 
> I believe that it is important that lmap-defined MAs be able to
> operate usefully in the broader ecosystem of MAs that also perform
> Measurement Methods at physical and link layers, and other "custom"
> Measurement Methods.

We agree on this.

> The lmap framework must not restrict or assume that all Measurement
> Methods that an MA supports are defined by ippm, defined by IETF, or
> that they are necessarily intended for use by end users or
> regulators or will be provided or useful to any other entity (than
> the one in charge of the MA). If the framework is written in such a
> way as to restrict lmap-defined MAs to only ever be used for ippm
> metrics, then that's a pretty useless framework, IMO. Many operators
> will be unwilling to have both lmap MA and a separate layer 1/2 MA,
> on the same device, using separate Control and Report
> protocols. Certainly, the lmap framework must not assume that all
> MAs are operated by service providers. Likewise, it must not assume
> that they are not operated by service providers. The framework needs
> to be sufficiently flexible to allow for all of the use cases that
> are to be supported by it.

We even agree on this.

> I have no desire for lmap to describe/define information or data
> models for these other Measurement Methods. I do have a desire to
> ensure that the lmap *framework* recognizes that MAs will include
> these, and to ensure that the *framework* recognizes this will occur
> and does not do anything to restrict or preclude this.

Here is where we may likely draw different conclusions from this
paragraph. If you are having MAs in mind that do not today and will
never in the future talk IP, then the LMAP protocol likely won't apply
to them and there won't be on the wire interoperability. Is that what
you have in mind?

My point is that we need to scope the work and set priorities and I
believe achieving on the wire interoperability is an important goal
for IP enabled MAs and must be a major goal for this work to be
useful.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From dromasca@avaya.com  Thu Sep 19 02:35:36 2013
Return-Path: 
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 9FBDE21F9473 for ; Thu, 19 Sep 2013 02:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.341
X-Spam-Level: 
X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 1jDRfj5c6yzG for ; Thu, 19 Sep 2013 02:35:30 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 445AF21F949F for ; Thu, 19 Sep 2013 02:35:28 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar0UAKDEOlLGmAcV/2dsb2JhbABbgmYhgQqDKb4EDQqBCxZtB4InAQEDEhERVwEVDQIGIAIEMBUSBBsah2EBmF+ER4o8kiWBKY4NgyE1gQADnlSLHYMkgio
X-IronPort-AV: E=Sophos;i="4.90,936,1371096000"; d="scan'208";a="24577059"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Sep 2013 05:35:20 -0400
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Sep 2013 05:32:36 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Thu, 19 Sep 2013 05:35:18 -0400
From: "Romascanu, Dan (Dan)" 
To: "lmap@ietf.org" 
Thread-Topic: lmap - New Meeting Session Request for IETF 88
Thread-Index: AQHOtRuN07gjG8UGskm0SKcz2TqqVQ==
Date: Thu, 19 Sep 2013 09:35:18 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128DE81A@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.46]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [lmap] lmap - New Meeting Session Request for IETF 88
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 09:35:36 -0000

SGksDQoNCkkgcmVxdWVzdGVkIGEgMi41IGhvdXJzIG1lZXRpbmcgc2xvdCBmb3IgTE1BUCBhdCBJ
RVRGLTg4LiANCg0KVGhlIGxpc3Qgb2YgRmlyc3QgUHJpb3JpdHkgY29uZmxpY3RzIGluY2x1ZGVz
OiBpcHBtIGVjcml0IGJtd2cgZGlzcGF0Y2ggbXB0Y3AgbmV0Y29uZiBuZXRtb2QgZGltZSBvcHNh
cmVhIG9wc2F3ZyByYWRleHQgc2FjbSB4cmJsb2NrIHJ0Y3dlYiB0aWN0b2MgaXJ0Zm9wZW4uDQoN
ClBsZWFzZSBsZXQgbWUgYW5kIEphc29uIGtub3cgaWYgdGhlcmUgaXMgYW55IG90aGVyIGNyaXRp
Y2FsIGNvbmZsaWN0IHRvIGF2b2lkLiANCg0KVGhhbmtzIGFuZCBSZWdhcmRzLA0KDQpEYW4NCg0K
DQoNCg==

From v.bajpai@jacobs-university.de  Thu Sep 19 03:07:12 2013
Return-Path: 
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 58D2F21F9946 for ; Thu, 19 Sep 2013 03:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 QHGUcHHzeS37 for ; Thu, 19 Sep 2013 03:07:07 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B905521F8CB4 for ; Thu, 19 Sep 2013 03:07:07 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A64020C0C for ; Thu, 19 Sep 2013 12:07:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id J-NknNdU5NfJ for ; Thu, 19 Sep 2013 12:07:07 +0200 (CEST)
Received: from exchange.jacobs-university.de (unknown [10.70.0.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id 03C6D20C02 for ; Thu, 19 Sep 2013 12:07:06 +0200 (CEST)
Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS04.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0158.001; Thu, 19 Sep 2013 12:07:03 +0200
From: "Bajpai, Vaibhav" 
To: "" 
Thread-Topic: LMAP acronym
Thread-Index: AQHOtR/8yfKi/NttxEa0knPP15lI2A==
Date: Thu, 19 Sep 2013 10:07:02 +0000
Message-ID: <6BECB2CA-D8CC-4562-A98B-661F37FDEEC7@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.50.203.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Bajpai, Vaibhav" 
Subject: [lmap] LMAP acronym
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 10:07:12 -0000

LMAP,

What does the acronym LMAP stand for? I ask because I see a bunch
of expansions used in the current documents (below). Wouldn't it=20
be nice to sync this into one expansion?=20

Thanks!

Best, Vaibhav

- Webpages:

lmap -- Large-Scale Measurement of Broadband Performance [1]
lmap -- Large Scale Measurement of Access network Performance [2]

[1] http://datatracker.ietf.org/wg/lmap/charter
[2] https://www.ietf.org/mailman/listinfo/lmap

- Internet Drafts:

lmap -- Large MeAsurement Platforms [1,2]
lmap -- Large-Scale Measurement Platforms [3,4]
lmap -- Large-Scale Measurement of Broadband Performance [5,6,7,8]
lmap -- Large scale Measurement of Access network Performance [9]
lmap -- large scale measurement of broadband performance [10]

[1] http://tools.ietf.org/html/draft-eardley-lmap-terminology-02
[2] http://tools.ietf.org/html/draft-bagnulo-lmap-http-00=20
[3] http://tools.ietf.org/html/draft-burbridge-lmap-information-model-00
[4] http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix-01
[5] http://tools.ietf.org/html/draft-eardley-lmap-framework-02
[6] http://tools.ietf.org/html/draft-akhter-lmap-framework-00
[7] http://tools.ietf.org/html/draft-seedorf-lmap-alto-01
[8] http://tools.ietf.org/html/draft-schoenw-lmap-netconf-00
[9] http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00
[10] http://tools.ietf.org/html/draft-huang-lmap-data-collection-use-case-0=
0

-----------------------------------------------------
Vaibhav Bajpai

Research I, Room 86
Computer Networks and Distributed Systems  (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com

From dromasca@avaya.com  Thu Sep 19 03:11:34 2013
Return-Path: 
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 8FEAB21F9343 for ; Thu, 19 Sep 2013 03:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.24
X-Spam-Level: 
X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 ckA4Ra3acCGd for ; Thu, 19 Sep 2013 03:11:29 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 38B5C21F9302 for ; Thu, 19 Sep 2013 03:11:29 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjsMANPMOlLGmAcV/2dsb2JhbABbgmYhOFKsYweUQoEhFnSCJQEBAQEDAQEBDygPJRcEAgEIDQMBBAEBCxQJBycLFAkIAgQBEggah2EBC50onF+PNjgGgxiBAAOZK4Upix2DJIIq
X-IronPort-AV: E=Sophos;i="4.90,936,1371096000"; d="scan'208";a="24580754"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Sep 2013 06:11:27 -0400
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Sep 2013 06:08:43 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Thu, 19 Sep 2013 06:11:25 -0400
From: "Romascanu, Dan (Dan)" 
To: "Bajpai, Vaibhav" , "" 
Thread-Topic: LMAP acronym
Thread-Index: AQHOtR/8yfKi/NttxEa0knPP15lI2JnM1saw
Date: Thu, 19 Sep 2013 10:11:24 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128DEAFA@AZ-FFEXMB04.global.avaya.com>
References: <6BECB2CA-D8CC-4562-A98B-661F37FDEEC7@jacobs-university.de>
In-Reply-To: <6BECB2CA-D8CC-4562-A98B-661F37FDEEC7@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.46]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [lmap] LMAP acronym
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 10:11:34 -0000

I suggest to use the expansion of acronyms in the charter.=20

Regards,

Dan




> -----Original Message-----
> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of
> Bajpai, Vaibhav
> Sent: Thursday, September 19, 2013 1:07 PM
> To: 
> Cc: Bajpai, Vaibhav
> Subject: [lmap] LMAP acronym
>=20
> LMAP,
>=20
> What does the acronym LMAP stand for? I ask because I see a bunch of
> expansions used in the current documents (below). Wouldn't it be nice to
> sync this into one expansion?
>=20
> Thanks!
>=20
> Best, Vaibhav
>=20
> - Webpages:
>=20
> lmap -- Large-Scale Measurement of Broadband Performance [1] lmap --
> Large Scale Measurement of Access network Performance [2]
>=20
> [1] http://datatracker.ietf.org/wg/lmap/charter
> [2] https://www.ietf.org/mailman/listinfo/lmap
>=20
> - Internet Drafts:
>=20
> lmap -- Large MeAsurement Platforms [1,2] lmap -- Large-Scale
> Measurement Platforms [3,4] lmap -- Large-Scale Measurement of Broadband
> Performance [5,6,7,8] lmap -- Large scale Measurement of Access network
> Performance [9] lmap -- large scale measurement of broadband performance
> [10]
>=20
> [1] http://tools.ietf.org/html/draft-eardley-lmap-terminology-02
> [2] http://tools.ietf.org/html/draft-bagnulo-lmap-http-00
> [3] http://tools.ietf.org/html/draft-burbridge-lmap-information-model-00
> [4] http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix-01
> [5] http://tools.ietf.org/html/draft-eardley-lmap-framework-02
> [6] http://tools.ietf.org/html/draft-akhter-lmap-framework-00
> [7] http://tools.ietf.org/html/draft-seedorf-lmap-alto-01
> [8] http://tools.ietf.org/html/draft-schoenw-lmap-netconf-00
> [9] http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00
> [10] http://tools.ietf.org/html/draft-huang-lmap-data-collection-use-
> case-00
>=20
> -----------------------------------------------------
> Vaibhav Bajpai
>=20
> Research I, Room 86
> Computer Networks and Distributed Systems  (CNDS) Lab School of
> Engineering and Sciences Jacobs University Bremen, Germany
>=20
> www.vaibhavbajpai.com
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap

From Michael.K.Bugenhagen@centurylink.com  Thu Sep 19 08:53:36 2013
Return-Path: 
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 96E4D21F8F97 for ; Thu, 19 Sep 2013 08:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.759
X-Spam-Level: 
X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599]
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 QhsyT2OfipWi for ; Thu, 19 Sep 2013 08:53:31 -0700 (PDT)
Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id D735721F93B9 for ; Thu, 19 Sep 2013 08:53:30 -0700 (PDT)
Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r8JFrQ78010250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Sep 2013 10:53:26 -0500 (CDT)
Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2BE7C1E006A; Thu, 19 Sep 2013 09:53:21 -0600 (MDT)
Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 0C3C21E0062; Thu, 19 Sep 2013 09:53:21 -0600 (MDT)
Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r8JFrKbF012920; Thu, 19 Sep 2013 09:53:20 -0600 (MDT)
Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r8JFrKJY012904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 09:53:20 -0600 (MDT)
Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.02.0318.001; Thu, 19 Sep 2013 10:53:19 -0500
From: "Bugenhagen, Michael K" 
To: "'Juergen Schoenwaelder'" , "STARK, BARBARA H" 
Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
Thread-Index: AQHOtEBhijCpI1mSFEe6iCtKUgenvpnL4EgAgAEYq4CAADlrIA==
Date: Thu, 19 Sep 2013 15:53:18 +0000
Message-ID: 
References: <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com>  <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> <20130918072600.GA46326@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130919070653.GA51566@elstar.local>
In-Reply-To: <20130919070653.GA51566@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [151.117.206.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: marcelo bagnulo braun , Brian Trammell , "lmap@ietf.org" 
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 15:53:36 -0000

Yes an Abstracted Test command framework / string is what I'm describing as=
 a universal standard so it's repeatable...=20
NOT a single protocol (this would be bad)

Defining a test is fine, however added information is required to ensure th=
e test was executed in the same fashion so the test results are comparable.
- So we'll need to go beyond the test attributes in order to do this... (be=
yond frame size, ...)
=20
Typical test implementation attributes I've had to define in the past

Test engine / Environmental factors
	-- Test engine (which TCP stack), no cross traffic, hour of day, target ty=
pe or class, ....

Test procedure factors
	-- Stability factor used (delay, or trending and how much), thresholds for=
 pass fail, Data trimming (95% of frames met x), ...

If these are not added to the Abstracted test command set I think we'll mis=
s the target.

Regards,
Mike









-----Original Message-----
From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Jue=
rgen Schoenwaelder
Sent: Thursday, September 19, 2013 2:07 AM
To: STARK, BARBARA H
Cc: marcelo bagnulo braun; lmap@ietf.org; Brian Trammell
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M=
A and Controller

On Wed, Sep 18, 2013 at 02:22:20PM +0000, STARK, BARBARA H wrote:
> > Frankly, for IP-layer and above measurements (this is what IPPM is=20
> > all about if I am not wrong), I fail to see why MAs would benefit=20
> > from being access technology specific. Obviously, MAs such as Ripe=20
> > Atlas probes or Sam Knows probes work on any access technology. The=20
> > same happens to be tru for pure software probes users run in Web=20
> > browsers or as apps. If we want to get LMAP MAs embedded into CPE=20
> > devices, then in at least some parts of the world, the CPE devices=20
> > are owned by the users and not the ISPs and they are pretty much=20
> > access technology independent (e.g. I have a cable model sitting in=20
> > front of my CPE/NAT router, for DSL lines you usually but a CPE/NAT=20
> > router that does the DSL stuff as well here in Germany but you can=20
> > still use it behind the Cable modem). I do see that there is a need to =
align the bootstrapping to whatever the access technology typically does.
> >=20
> > The IETF is usually about wire interoperability and the simple=20
> > reason is that an open standard allows to create a market around it=20
> > which has typically benefits for many stakeholders involved. I like=20
> > to understand why this does not apply to LMAP in general. In other=20
> > words, some of the use case should explain clearly why on the wire inte=
roperability is a non-achievable goal.
>=20
> I believe that it is important that lmap-defined MAs be able to=20
> operate usefully in the broader ecosystem of MAs that also perform=20
> Measurement Methods at physical and link layers, and other "custom"
> Measurement Methods.

We agree on this.

> The lmap framework must not restrict or assume that all Measurement=20
> Methods that an MA supports are defined by ippm, defined by IETF, or=20
> that they are necessarily intended for use by end users or regulators=20
> or will be provided or useful to any other entity (than the one in=20
> charge of the MA). If the framework is written in such a way as to=20
> restrict lmap-defined MAs to only ever be used for ippm metrics, then=20
> that's a pretty useless framework, IMO. Many operators will be=20
> unwilling to have both lmap MA and a separate layer 1/2 MA, on the=20
> same device, using separate Control and Report protocols. Certainly,=20
> the lmap framework must not assume that all MAs are operated by=20
> service providers. Likewise, it must not assume that they are not=20
> operated by service providers. The framework needs to be sufficiently=20
> flexible to allow for all of the use cases that are to be supported by=20
> it.

We even agree on this.

> I have no desire for lmap to describe/define information or data=20
> models for these other Measurement Methods. I do have a desire to=20
> ensure that the lmap *framework* recognizes that MAs will include=20
> these, and to ensure that the *framework* recognizes this will occur=20
> and does not do anything to restrict or preclude this.

Here is where we may likely draw different conclusions from this paragraph.=
 If you are having MAs in mind that do not today and will never in the futu=
re talk IP, then the LMAP protocol likely won't apply to them and there won=
't be on the wire interoperability. Is that what you have in mind?

My point is that we need to scope the work and set priorities and I believe=
 achieving on the wire interoperability is an important goal for IP enabled=
 MAs and must be a major goal for this work to be useful.

/js

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         
_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap

From bs7652@att.com  Thu Sep 19 10:40:22 2013
Return-Path: 
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 DFB7921F960D for ; Thu, 19 Sep 2013 10:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.699
X-Spam-Level: 
X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 xG1ZkAWlEFsG for ; Thu, 19 Sep 2013 10:40:14 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id CC44821F8B4E for ; Thu, 19 Sep 2013 10:40:13 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id af63b325.0.5197479.00-162.14441503.nbfkord-smmo05.seg.att.com (envelope-from );  Thu, 19 Sep 2013 17:40:14 +0000 (UTC)
X-MXL-Hash: 523b36fe2804e810-ac82c5a4944fc16312fa24bbcfe190034737b751
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8JHe9Is020029; Thu, 19 Sep 2013 13:40:10 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8JHdx82019849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Sep 2013 13:40:02 -0400
Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (GAALPA1MSGHUB9F.itservices.sbc.com [130.8.36.92]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 19 Sep 2013 17:39:44 GMT
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.03.0158.001; Thu, 19 Sep 2013 13:39:44 -0400
From: "STARK, BARBARA H" 
To: Juergen Schoenwaelder 
Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
Thread-Index: AQHOtEBmosHnAD2uTEyRx3kEALw3KJnLcBFggAF4H4CAACIwoA==
Date: Thu, 19 Sep 2013 17:39:43 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E611303729CD@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com>  <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> <20130918072600.GA46326@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130919070653.GA51566@elstar.local>
In-Reply-To: <20130919070653.GA51566@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.122.170]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=U0I4pL-mzOoA:10 a=l4EBnxoveaQA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=Lb5Mp4LI0xsA:10 a=VUYFUp9cZxb4iNCaHKQA:9 a=CjuIK1]
X-AnalysisOut: [q_8ugA:10 a=K57UIlPIY6LHk4C1:21 a=_gIYZwaTpobBK0eb:21]
Cc: "lmap@ietf.org" 
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 17:40:22 -0000

> > I have no desire for lmap to describe/define information or data
> > models for these other Measurement Methods. I do have a desire to
> > ensure that the lmap *framework* recognizes that MAs will include
> > these, and to ensure that the *framework* recognizes this will occur
> > and does not do anything to restrict or preclude this.
>=20
> Here is where we may likely draw different conclusions from this paragrap=
h.
> If you are having MAs in mind that do not today and will never in the fut=
ure
> talk IP, then the LMAP protocol likely won't apply to them and there won'=
t be
> on the wire interoperability. Is that what you have in mind?
>=20
> My point is that we need to scope the work and set priorities and I belie=
ve
> achieving on the wire interoperability is an important goal for IP enable=
d MAs
> and must be a major goal for this work to be useful.

In the context of lmap, I am only interested in devices capable of communic=
ating across the Internet. Devices that cannot talk IP are of no interest t=
o me.
If the framework stated criteria such as "a Control protocol MUST operate o=
ver IP" and "a Reporting protocol MUST operate over IP", I would consider t=
his very reasonable. But interoperability at the IP layer <> on-the-wire (a=
pplication) interoperability.

In the content of Measurement Method protocols), on-the-wire interoperabili=
ty for a given Measurement Method, among all endpoints claiming support for=
 that Measurement Method is critical. This is something for ippm to work (a=
s it relates to various IP Measurement Methods), and it is also something t=
hat the information model can help ensure (by including model elements for =
MAs to tell Controllers what Measurement Methods they support and including=
 full information model support of the proposed ippm registry). The reason =
this is important, is that we understand IP Measurement Methods need to be =
able to run between MAs and MPs of different domains.

The lmap charter states "A key assumption constraining the initial work is =
that the measurement system is under the control of a single organization".=
 The framework currently lists constraints of "Measurement system is under =
the direction of a single organization" and "Each MA may only have a single=
 Controller at any point in time". These are very important constraints. Th=
ese constraints mean to me that there is no need for a requirement for on-t=
he-wire (application) interoperability of Control protocol or Reporting pro=
tocol between MAs/Controllers/Collectors of different organizations. Only i=
ntra-organization interoperability is required and each organization is fre=
e to determine what protocols to use in these contexts, without having any =
impact on inter-organization Measurement Method interoperability -- as long=
 as the protocol properly supports the lmap information model.

 However, if there is consensus that the lmap framework has to man=
date on-the-wire interoperability between *all* MAs, Controllers, and Colle=
ctors of different organizations, I would strongly recommend making use of =
RFC6919 language. Such as:
MAs and Controllers MUST use the lmap-selected Control Protocol (BUT WE KNO=
W YOU WON'T because organizations will have other protocols available for t=
hem to choose from, we recognize that these organizations will use criteria=
 not listed in this document to determine which protocol is right for them,=
 and we recognize that on-the-wire interoperability with other organization=
s' Controllers and MAs is likely not to be a criterion for many organizatio=
ns).
Alternately, the framework could say "MAs and Controllers OUGHT TO use the =
lmap-selected Control Protocol". 
Personally, I would prefer for the framework to avoid any statement of this=
 sort.

Some protocol criteria that might be useful are:
The Control Protocol MUST operate over IP. Note that where Controller and M=
A are in the same physical device, there is no need for a Control Protocol =
to be used.
The Control Protocol MUST include support for all Controller-MA elements of=
 the Information Model. This includes support for all Measurement Methods i=
dentified in [ippm registry].
The Control Protocol MUST be extensible, so it can include support for Meas=
urement Methods defined external to IETF, and for other industry-segment-sp=
ecific or even organization-specific information elements.
Barbara

From bs7652@att.com  Thu Sep 19 11:54:07 2013
Return-Path: 
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 AF11421F8D12 for ; Thu, 19 Sep 2013 11:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.686
X-Spam-Level: 
X-Spam-Status: No, score=-6.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 EplCc7rVxQ+x for ; Thu, 19 Sep 2013 11:54:01 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDD821F8C3E for ; Thu, 19 Sep 2013 11:54:01 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 9484b325.50b3d940.5247860.00-539.14585568.nbfkord-smmo05.seg.att.com (envelope-from );  Thu, 19 Sep 2013 18:54:01 +0000 (UTC)
X-MXL-Hash: 523b48496ad753c9-28558cc5fda8a61917f2f6cfe5e8e8c45c73910a
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 0484b325.0.5247780.00-072.14585354.nbfkord-smmo05.seg.att.com (envelope-from );  Thu, 19 Sep 2013 18:53:53 +0000 (UTC)
X-MXL-Hash: 523b4841484f8c7d-a0c63090689ec76de13f4f73ca24f0102ef408d5
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8JIrquV026362; Thu, 19 Sep 2013 14:53:52 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8JIrenZ026120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Sep 2013 14:53:48 -0400
Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 19 Sep 2013 18:53:25 GMT
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0158.001; Thu, 19 Sep 2013 14:53:25 -0400
From: "STARK, BARBARA H" 
To: "Bugenhagen, Michael K" 
Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
Thread-Index: AQHOtEBmosHnAD2uTEyRx3kEALw3KJnLcBFggAF4H4CAAJMUAP//5LOQ
Date: Thu, 19 Sep 2013 18:53:25 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130372B43@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <2D09D61DDFA73D4C884805CC7865E61130370991@GAALPA1MSGUSR9L.ITServices.sbc.com>  <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> <20130918072600.GA46326@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130919070653.GA51566@elstar.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.122.170]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=U0I4pL-mzOoA:10 a=l4EBnxoveaQA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=Lb5Mp4LI0xsA:10 a=48vgC7mUAAAA:8 a=PMN0vDWF5t6NQU]
X-AnalysisOut: [Kbx-4A:9 a=CjuIK1q_8ugA:10]
Cc: "lmap@ietf.org" 
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 18:54:07 -0000

> Defining a test is fine, however added information is required to ensure =
the
> test was executed in the same fashion so the test results are comparable.
> - So we'll need to go beyond the test attributes in order to do this... (=
beyond
> frame size, ...)
>=20
> Typical test implementation attributes I've had to define in the past
>=20
> Test engine / Environmental factors
> 	-- Test engine (which TCP stack), no cross traffic, hour of day, target
> type or class, ....
>=20
> Test procedure factors
> 	-- Stability factor used (delay, or trending and how much), thresholds
> for pass fail, Data trimming (95% of frames met x), ...
>=20
> If these are not added to the Abstracted test command set I think we'll m=
iss
> the target.

Hi Mike,
In http://tools.ietf.org/html/draft-burbridge-lmap-information-model-00 (wh=
ich I hope will be used as a basis for lmap's Information Model deliverable=
), there's currently a section on Reporting Information that includes an "M=
A Context" element. IMO, the information you describe belongs here. Since y=
ou seem to have an idea of what you'd like to see included in Reporting Inf=
ormation, perhaps you could provide a more specific and "normalized" list t=
hat notes where you think the particular element is a string, datetime, enu=
merated list (and provide enumerations), etc.=20

Perhaps the authors of that draft could say whether they'd like that sort o=
f input, and if there's some sort of format they'd like to get that input i=
n.

Anyway, I don't think there needs to be discussion about whether or not wha=
t you ask for is in scope of lmap. I think it's just a matter of getting th=
e specifics of what it is fleshed out in the Information Model. At the leve=
l of the framework, I think what the framework currently says is great (see=
 below). But maybe you would like to propose an additional bullet to expoun=
d in a single sentence or so a bit more on the idea of "context".
Barbara

------------------ from http://tools.ietf.org/html/draft-eardley-lmap-frame=
work-02 ----
4.1.  Information Model
... snip ...
   The Information Model is divided into two main parts, each of which
   may be broken down into sub-parts:
... snip ...
   o  information about the Report: Information transmitted from the MA
      to the Collector including measurement results and the context in
      which they were conducted.  This includes:

      *  the MAs identifier, or perhaps a Group-ID to anonymise results

      *  the actual Measurement Results, including the time they were
         measured

      *  the details of the Measurement Task (to avoid the Collector
         having to ask the Controller for this information later)

From j.schoenwaelder@jacobs-university.de  Thu Sep 19 12:50:58 2013
Return-Path: 
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 3A77A21F8427 for ; Thu, 19 Sep 2013 12:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.156
X-Spam-Level: 
X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 iSVsU94hHHjY for ; Thu, 19 Sep 2013 12:50:52 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0EE21F842B for ; Thu, 19 Sep 2013 12:50:51 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A2EA20C11; Thu, 19 Sep 2013 21:50:50 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mvKhwKdX9cVs; Thu, 19 Sep 2013 21:50:50 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D425620C10; Thu, 19 Sep 2013 21:50:49 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5A45828730F5; Thu, 19 Sep 2013 21:50:43 +0200 (CEST)
Date: Thu, 19 Sep 2013 21:50:42 +0200
From: Juergen Schoenwaelder 
To: "STARK, BARBARA H" 
Message-ID: <20130919195041.GA1760@elstar.local>
Mail-Followup-To: "STARK, BARBARA H" , "lmap@ietf.org" 
References: <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> <20130918072600.GA46326@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130919070653.GA51566@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303729CD@GAALPA1MSGUSR9L.ITServices.sbc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303729CD@GAALPA1MSGUSR9L.ITServices.sbc.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "lmap@ietf.org" 
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 19:50:58 -0000

On Thu, Sep 19, 2013 at 05:39:43PM +0000, STARK, BARBARA H wrote:
> > > I have no desire for lmap to describe/define information or data
> > > models for these other Measurement Methods. I do have a desire to
> > > ensure that the lmap *framework* recognizes that MAs will include
> > > these, and to ensure that the *framework* recognizes this will occur
> > > and does not do anything to restrict or preclude this.
> > 
> > Here is where we may likely draw different conclusions from this paragraph.
> > If you are having MAs in mind that do not today and will never in the future
> > talk IP, then the LMAP protocol likely won't apply to them and there won't be
> > on the wire interoperability. Is that what you have in mind?
> > 
> > My point is that we need to scope the work and set priorities and I believe
> > achieving on the wire interoperability is an important goal for IP enabled MAs
> > and must be a major goal for this work to be useful.
> 
> In the context of lmap, I am only interested in devices capable of communicating across the Internet. Devices that cannot talk IP are of no interest to me.
> If the framework stated criteria such as "a Control protocol MUST operate over IP" and "a Reporting protocol MUST operate over IP", I would consider this very reasonable. But interoperability at the IP layer <> on-the-wire (application) interoperability.
> 
> In the content of Measurement Method protocols), on-the-wire interoperability for a given Measurement Method, among all endpoints claiming support for that Measurement Method is critical. This is something for ippm to work (as it relates to various IP Measurement Methods), and it is also something that the information model can help ensure (by including model elements for MAs to tell Controllers what Measurement Methods they support and including full information model support of the proposed ippm registry). The reason this is important, is that we understand IP Measurement Methods need to be able to run between MAs and MPs of different domains.
> 
> The lmap charter states "A key assumption constraining the initial work is that the measurement system is under the control of a single organization". The framework currently lists constraints of "Measurement system is under the direction of a single organization" and "Each MA may only have a single Controller at any point in time". These are very important constraints. These constraints mean to me that there is no need for a requirement for on-the-wire (application) interoperability of Control protocol or Reporting protocol between MAs/Controllers/Collectors of different organizations. Only intra-organization interoperability is required and each organization is free to determine what protocols to use in these contexts, without having any impact on inter-organization Measurement Method interoperability -- as long as the protocol properly supports the lmap information model.

Frankly,

I think your logic is screwed. Yes, there is an assumption that the
measurement system is under the control of a single organization. You
seem to conclude from this that there is no value in defining a common
protocol. My understanding, however, is that this statement is there
since the stated assumption simplifies MAs and in particular the
protocol between MAs and controllers since there is no coordination
needed between multiple controllers from different domains. I believe
there is value in producing a common protocol. But like all protocols,
organizations will be free to decide whether they like to deploy them
or use something else. Hence, I do not really know what your issue is
here.

>  However, if there is consensus that the lmap framework has to mandate on-the-wire interoperability between *all* MAs, Controllers, and Collectors of different organizations, I would strongly recommend making use of RFC6919 language. Such as:
> MAs and Controllers MUST use the lmap-selected Control Protocol (BUT WE KNOW YOU WON'T because organizations will have other protocols available for them to choose from, we recognize that these organizations will use criteria not listed in this document to determine which protocol is right for them, and we recognize that on-the-wire interoperability with other organizations' Controllers and MAs is likely not to be a criterion for many organizations).
> Alternately, the framework could say "MAs and Controllers OUGHT TO use the lmap-selected Control Protocol". 

I will not comment on your attempt at producing sarcasm.

> Personally, I would prefer for the framework to avoid any statement of this sort.
> 
> Some protocol criteria that might be useful are:
> The Control Protocol MUST operate over IP. Note that where Controller and MA are in the same physical device, there is no need for a Control Protocol to be used.

> The Control Protocol MUST include support for all Controller-MA elements of the Information Model. This includes support for all Measurement Methods identified in [ippm registry].

This is IMHO non-sense. Requiring support for _all_ measurements
methods registered is not meaningful. This MUST is not implementable
as the registry can change any time (nor is the implementation of all
measurement methods at a given snapshot in time necessarily
meaningful).

> The Control Protocol MUST be extensible, so it can include support for Measurement Methods defined external to IETF, and for other industry-segment-specific or even organization-specific information elements.

Whatever an 'information element' is here...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From timothy.carey@alcatel-lucent.com  Sun Sep 22 18:21:53 2013
Return-Path: 
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 3B19621F9D15 for ; Sun, 22 Sep 2013 18:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level: 
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-1.999, BAYES_50=0.001, 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 ytmvxaLFkDnK for ; Sun, 22 Sep 2013 18:21:47 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDE721F9D0D for ; Sun, 22 Sep 2013 18:21:34 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r8N1LWiR015809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 22 Sep 2013 20:21:32 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r8N1LUeu017987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Sep 2013 21:21:32 -0400
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Sun, 22 Sep 2013 21:21:31 -0400
From: "Carey, Timothy (Timothy)" 
To: Juergen Schoenwaelder , "STARK, BARBARA H" 
Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
Thread-Index: AQHOtjPQOMmHuHfzwEqvMYanviEoqZnSgrTA
Date: Mon, 23 Sep 2013 01:21:30 +0000
Message-ID: <9966516C6EB5FC4381E05BF80AA55F771E7353@US70UWXCHMBA05.zam.alcatel-lucent.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> <20130918072600.GA46326@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130919070653.GA51566@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303729CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130919195041.GA1760@elstar.local>
In-Reply-To: <20130919195041.GA1760@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "lmap@ietf.org" 
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 01:21:53 -0000

Juergen and Barbara,


Sorry - I was trying to read this thread and I am not sure exactly what the=
 issue/questions are, but there
Were a couple of topics that I wanted to express an opinion on.

A common framework (MA, Controllers, Collectors) are a good thing and we sh=
ould continue this work.

We need to define the requirements of any protocol between the elements of =
the framework; with the goal that different organizations may want differen=
t protocol implementations. For example one organization may want to utiliz=
e the BBF CWMP and IPDR protocols for framework elements within their admin=
istrative domain.=20

>From the requirements, the IETF could specify a protocol implementation but=
 we must realize and allow for other protocols.


A common protocol neutral information model is a good thing; the LMAP group=
 has a very good start in this process. However again we must allow for dif=
ferent implementation (representations) of the information model. Again an =
organization that would utilize the BBF CWMP and IPDR protocols would repre=
sent the information model as a CWMP data model. As such the Information mo=
del should be designed to allow for protocol specific attributes as first c=
lass entities and attributes. I can't see how that is done.

Likewise, the IETF could specify a protocol specific data model implementat=
ion but again we must realize and allow for other data model implementation=
 of the information model.


As to the question of should framework elements be required to implement al=
l the IPPM measurements; IMHO the answer to that is no unless the registry =
would contain only the basic of measurements. Instead we should ensure the =
framework and protocols allow for elements in the framework to state what t=
he measurements and capabilities of a measurement they support. We should a=
lso allow for extensions to measurement registry; or have a mechanism for o=
rganizations to define their measurements that they would use in their admi=
nistrative domain.

If we do these things, IMHO, we could have a framework that is used effecti=
vely by the different stakeholders.

Juergen, to answer your very real concern regarding inter-organization test=
ing. If this was needed, wouldn't an organization that uses another protoco=
l simply provide the controllers and collectors for these "unmanaged" MAs u=
sing the MA's protocol?

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: Friday, September 20, 2013 2:51 AM
To: STARK, BARBARA H
Cc: lmap@ietf.org
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between M=
A and Controller

On Thu, Sep 19, 2013 at 05:39:43PM +0000, STARK, BARBARA H wrote:
> > > I have no desire for lmap to describe/define information or data
> > > models for these other Measurement Methods. I do have a desire to
> > > ensure that the lmap *framework* recognizes that MAs will include
> > > these, and to ensure that the *framework* recognizes this will occur
> > > and does not do anything to restrict or preclude this.
> >=20
> > Here is where we may likely draw different conclusions from this paragr=
aph.
> > If you are having MAs in mind that do not today and will never in the f=
uture
> > talk IP, then the LMAP protocol likely won't apply to them and there wo=
n't be
> > on the wire interoperability. Is that what you have in mind?
> >=20
> > My point is that we need to scope the work and set priorities and I bel=
ieve
> > achieving on the wire interoperability is an important goal for IP enab=
led MAs
> > and must be a major goal for this work to be useful.
>=20
> In the context of lmap, I am only interested in devices capable of commun=
icating across the Internet. Devices that cannot talk IP are of no interest=
 to me.
> If the framework stated criteria such as "a Control protocol MUST operate=
 over IP" and "a Reporting protocol MUST operate over IP", I would consider=
 this very reasonable. But interoperability at the IP layer <> on-the-wire =
(application) interoperability.
>=20
> In the content of Measurement Method protocols), on-the-wire interoperabi=
lity for a given Measurement Method, among all endpoints claiming support f=
or that Measurement Method is critical. This is something for ippm to work =
(as it relates to various IP Measurement Methods), and it is also something=
 that the information model can help ensure (by including model elements fo=
r MAs to tell Controllers what Measurement Methods they support and includi=
ng full information model support of the proposed ippm registry). The reaso=
n this is important, is that we understand IP Measurement Methods need to b=
e able to run between MAs and MPs of different domains.
>=20
> The lmap charter states "A key assumption constraining the initial work i=
s that the measurement system is under the control of a single organization=
". The framework currently lists constraints of "Measurement system is unde=
r the direction of a single organization" and "Each MA may only have a sing=
le Controller at any point in time". These are very important constraints. =
These constraints mean to me that there is no need for a requirement for on=
-the-wire (application) interoperability of Control protocol or Reporting p=
rotocol between MAs/Controllers/Collectors of different organizations. Only=
 intra-organization interoperability is required and each organization is f=
ree to determine what protocols to use in these contexts, without having an=
y impact on inter-organization Measurement Method interoperability -- as lo=
ng as the protocol properly supports the lmap information model.

Frankly,

I think your logic is screwed. Yes, there is an assumption that the
measurement system is under the control of a single organization. You
seem to conclude from this that there is no value in defining a common
protocol. My understanding, however, is that this statement is there
since the stated assumption simplifies MAs and in particular the
protocol between MAs and controllers since there is no coordination
needed between multiple controllers from different domains. I believe
there is value in producing a common protocol. But like all protocols,
organizations will be free to decide whether they like to deploy them
or use something else. Hence, I do not really know what your issue is
here.

>  However, if there is consensus that the lmap framework has to m=
andate on-the-wire interoperability between *all* MAs, Controllers, and Col=
lectors of different organizations, I would strongly recommend making use o=
f RFC6919 language. Such as:
> MAs and Controllers MUST use the lmap-selected Control Protocol (BUT WE K=
NOW YOU WON'T because organizations will have other protocols available for=
 them to choose from, we recognize that these organizations will use criter=
ia not listed in this document to determine which protocol is right for the=
m, and we recognize that on-the-wire interoperability with other organizati=
ons' Controllers and MAs is likely not to be a criterion for many organizat=
ions).
> Alternately, the framework could say "MAs and Controllers OUGHT TO use th=
e lmap-selected Control Protocol". 

I will not comment on your attempt at producing sarcasm.

> Personally, I would prefer for the framework to avoid any statement of th=
is sort.
>=20
> Some protocol criteria that might be useful are:
> The Control Protocol MUST operate over IP. Note that where Controller and=
 MA are in the same physical device, there is no need for a Control Protoco=
l to be used.

> The Control Protocol MUST include support for all Controller-MA elements =
of the Information Model. This includes support for all Measurement Methods=
 identified in [ippm registry].

This is IMHO non-sense. Requiring support for _all_ measurements
methods registered is not meaningful. This MUST is not implementable
as the registry can change any time (nor is the implementation of all
measurement methods at a given snapshot in time necessarily
meaningful).

> The Control Protocol MUST be extensible, so it can include support for Me=
asurement Methods defined external to IETF, and for other industry-segment-=
specific or even organization-specific information elements.

Whatever an 'information element' is here...

/js

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         


From philip.eardley@bt.com  Mon Sep 23 01:47:42 2013
Return-Path: 
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 A8BA121F9AE7 for ; Mon, 23 Sep 2013 01:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.555
X-Spam-Level: 
X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 jcUzgKhTrdes for ; Mon, 23 Sep 2013 01:47:35 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id E333C11E8171 for ; Mon, 23 Sep 2013 01:47:33 -0700 (PDT)
Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 23 Sep 2013 09:47:32 +0100
Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.51]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Mon, 23 Sep 2013 09:47:32 +0100
From: 
To: 
Date: Mon, 23 Sep 2013 09:47:27 +0100
Thread-Topic: Merged framework draft
Thread-Index: Ac64OWpJZzk6ojk7TGeVOttUV8E7gA==
Message-ID: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9CFD7CEEMV67UKRDdoma_"
MIME-Version: 1.0
Subject: [lmap] Merged framework draft
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 08:47:42 -0000

--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9CFD7CEEMV67UKRDdoma_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We have been working on a framework draft that merges the previous 2 framew=
ork drafts & the terminology draft, as well as including various things tha=
t have been discussed on the list since.
Our plan is to produce an update before the Vancouver deadline. We have a f=
ew things that we're planning to work on, but we wanted to get it out in or=
der to get everyone else's comments.
http://www.ietf.org/id/draft-folks-lmap-framework-00.txt

Terminology:
Information Model definition tweaked, new definition for Subscriber and Tes=
t Traffic.

Protocol Model:
Added a high-level protocol model

Privacy considerations:
A substantial new section. It may be better removing it and security consid=
erations into a new draft about threats and how to alleviate them?

Looking forward to the discussions!
Phil, Al, Paul, Marcelo, Aamer, Trevor.

--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9CFD7CEEMV67UKRDdoma_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


We have been working on a=
 framework draft that merges the previous 2 framework drafts & the term=
inology draft, as well as including various things that have been discussed=
 on the list since. 
Our plan is to produ=
ce an update before the Vancouver deadline. We have a few things that we=
217;re planning to work on, but we wanted to get it out in order to get eve=
ryone else’s comments.
http://www.ietf.org=
/id/draft-folks-lmap-framework-00.txt 
 
Terminology:
=

Information Model definition tweaked, new definition for Subscr=
iber and Test Traffic.
 
Protocol Model:
Added=
 a high-level protocol model  
&=
nbsp;
Privacy considerations:=

A substantial new section. It may be better removing it and=
 security considerations into a new draft about threats and how to alleviat=
e them?
 
Looking forward to the discussions!
=
Phil, Al, Paul, Marcelo, Aamer, Trevor.
<=
/html>=

--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9CFD7CEEMV67UKRDdoma_--

From dromasca@avaya.com  Mon Sep 23 01:56:37 2013
Return-Path: 
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 EB3AE21F9E45 for ; Mon, 23 Sep 2013 01:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.279
X-Spam-Level: 
X-Spam-Status: No, score=-103.279 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Eo0AeOZMpGQM for ; Mon, 23 Sep 2013 01:56:31 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 37C3821F8201 for ; Mon, 23 Sep 2013 01:56:30 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQKAPMBQFLGmAcV/2dsb2JhbABZgkMjIThShgqmUZRVgRsWdIIlAQEBAQMSG1wCAQgNBAQBAQsdBzIUCQgBAQQBEggBGYdjAQudXJwwF480NwGDHoEAA5QfijaLHoMkgio
X-IronPort-AV: E=Sophos;i="4.90,960,1371096000"; d="scan'208,217";a="28855166"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Sep 2013 04:56:29 -0400
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Sep 2013 04:53:32 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Mon, 23 Sep 2013 10:56:28 +0200
From: "Romascanu, Dan (Dan)" 
To: "philip.eardley@bt.com" , "lmap@ietf.org" 
Thread-Topic: Merged framework draft
Thread-Index: Ac64OWpJZzk6ojk7TGeVOttUV8E7gAAAODBw
Date: Mon, 23 Sep 2013 08:56:27 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128E22FE@AZ-FFEXMB04.global.avaya.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA128E22FEAZFFEXMB04globa_"
MIME-Version: 1.0
Subject: Re: [lmap] Merged framework draft
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 08:56:37 -0000

--_000_9904FB1B0159DA42B0B887B7FA8119CA128E22FEAZFFEXMB04globa_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Thanks to Philip and all the authors for the good work.

We need however to be a little more aggressive. The WG charter includes the=
 following milestone.

Sep 2013

Initial WG I-D for the LMAP Framework including terminology


According to the authors - is this I-D in good enough shape for becoming th=
e initial WG I-D? If the authors say 'yes' the chairs can ask on the WG lis=
t about consensus on this issue.

We have a similar milestone for the Use Cases document.

Regards,

Dan



From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi=
lip.eardley@bt.com
Sent: Monday, September 23, 2013 11:47 AM
To: lmap@ietf.org
Subject: [lmap] Merged framework draft

We have been working on a framework draft that merges the previous 2 framew=
ork drafts & the terminology draft, as well as including various things tha=
t have been discussed on the list since.
Our plan is to produce an update before the Vancouver deadline. We have a f=
ew things that we're planning to work on, but we wanted to get it out in or=
der to get everyone else's comments.
http://www.ietf.org/id/draft-folks-lmap-framework-00.txt

Terminology:
Information Model definition tweaked, new definition for Subscriber and Tes=
t Traffic.

Protocol Model:
Added a high-level protocol model

Privacy considerations:
A substantial new section. It may be better removing it and security consid=
erations into a new draft about threats and how to alleviate them?

Looking forward to the discussions!
Phil, Al, Paul, Marcelo, Aamer, Trevor.

--_000_9904FB1B0159DA42B0B887B7FA8119CA128E22FEAZFFEXMB04globa_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,<=
/p>

 


Thanks to Philip and a=
ll the authors for the good work.



 


We need however to be =
a little more aggressive. The WG charter includes the following milestone.



 








Sep 2013 





Initial WG I-D for the LMAP Framework including terminolog=
y








 


According to the autho=
rs – is this I-D in good enough shape for becoming the initial WG I-D=
? If the authors say ‘yes’ the chairs can ask on the WG list ab=
out consensus on this issue.



 


We have a similar mile=
stone for the Use Cases document.



 


Regards,


 


Dan<=
/p>

 


 


 








From: lmap-bou=
nces@ietf.org [mailto:lmap-bounces@ietf.org]
On Behalf Of philip.eardley@bt.com

Sent: Monday, September 23, 2013 11:47 AM

To: lmap@ietf.org

Subject: [lmap] Merged framework draft






 


We have been working on a =
framework draft that merges the previous 2 framework drafts & the termi=
nology draft, as well as including various things that have been
 discussed on the list since. 


Our plan is to produce an =
update before the Vancouver deadline. We have a few things that we’re=
 planning to work on, but we wanted to get it out in order to get
 everyone else’s comments.


http://www.ietf.org/id/draft-fol=
ks-lmap-framework-00.txt



 

Terminology:


Information Model definiti=
on tweaked, new definition for Subscriber and Test Traffic.


 

Protocol Model:=



Added a high-level protoco=
l model  


 

Privacy considerations:


A substantial new section.=
 It may be better removing it and security considerations into a new draft =
about threats and how to alleviate them?


 

Looking forward to the dis=
cussions!


Phil, Al, Paul, Marcelo, A=
amer, Trevor.








--_000_9904FB1B0159DA42B0B887B7FA8119CA128E22FEAZFFEXMB04globa_--

From philip.eardley@bt.com  Mon Sep 23 02:04:09 2013
Return-Path: 
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 4EE7121F9D74 for ; Mon, 23 Sep 2013 02:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.257
X-Spam-Level: 
X-Spam-Status: No, score=-103.257 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 fmYsk4s3Veuk for ; Mon, 23 Sep 2013 02:04:05 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 248A321F9D52 for ; Mon, 23 Sep 2013 02:04:04 -0700 (PDT)
Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 23 Sep 2013 10:04:03 +0100
Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.51]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 23 Sep 2013 10:04:02 +0100
From: 
To: , 
Date: Mon, 23 Sep 2013 10:04:02 +0100
Thread-Topic: Merged framework draft
Thread-Index: Ac64OWpJZzk6ojk7TGeVOttUV8E7gAAAODBwAABhXIA=
Message-ID: 
References:  <9904FB1B0159DA42B0B887B7FA8119CA128E22FE@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128E22FE@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9CFD7E0EMV67UKRDdoma_"
MIME-Version: 1.0
Subject: Re: [lmap] Merged framework draft
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 09:04:09 -0000

--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9CFD7E0EMV67UKRDdoma_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Personally I think it is

From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: 23 September 2013 09:56
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: Merged framework draft

Hi,

Thanks to Philip and all the authors for the good work.

We need however to be a little more aggressive. The WG charter includes the=
 following milestone.

Sep 2013

Initial WG I-D for the LMAP Framework including terminology


According to the authors - is this I-D in good enough shape for becoming th=
e initial WG I-D? If the authors say 'yes' the chairs can ask on the WG lis=
t about consensus on this issue.

We have a similar milestone for the Use Cases document.

Regards,

Dan



From: lmap-bounces@ietf.org [mailto:lmap-boun=
ces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, September 23, 2013 11:47 AM
To: lmap@ietf.org
Subject: [lmap] Merged framework draft

We have been working on a framework draft that merges the previous 2 framew=
ork drafts & the terminology draft, as well as including various things tha=
t have been discussed on the list since.
Our plan is to produce an update before the Vancouver deadline. We have a f=
ew things that we're planning to work on, but we wanted to get it out in or=
der to get everyone else's comments.
http://www.ietf.org/id/draft-folks-lmap-framework-00.txt

Terminology:
Information Model definition tweaked, new definition for Subscriber and Tes=
t Traffic.

Protocol Model:
Added a high-level protocol model

Privacy considerations:
A substantial new section. It may be better removing it and security consid=
erations into a new draft about threats and how to alleviate them?

Looking forward to the discussions!
Phil, Al, Paul, Marcelo, Aamer, Trevor.

--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9CFD7E0EMV67UKRDdoma_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Personally I t=
hink it is
 
From:<=
span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri=
f"'> Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] 
Sent: 23 S=
eptember 2013 09:56
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.orgSubject: RE: Merged framework draft
 
Hi,
 
Thanks to =
Philip and all the authors for the good work. 
 <=
/span>
W=
e need however to be a little more aggressive. The WG charter includes the =
following milestone. 
 
&nb=
sp;
According to the authors – is this I-D in good enough shape =
for becoming the initial WG I-D? If the authors say ‘yes’ the c=
hairs can ask on the WG list about consensus on this issue. 
 
We have a similar milestone for the Use Cases document. <=
/o:p>
 
Regards,
 
Dan
 
 
 
From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent:<=
/b> Monday, September 23, 2013 11:47 AM
To: lmap@ietf.org
Subject: [lmap] Merged framework dr=
aft
 
We have been working on a framewo=
rk draft that merges the previous 2 framework drafts & the terminology =
draft, as well as including various things that have been discussed on the =
list since. 
Our plan is to produce an upd=
ate before the Vancouver deadline. We have a few things that we’re pl=
anning to work on, but we wanted to get it out in order to get everyone els=
e’s comments.
http://www.ietf.org/id/dra=
ft-folks-lmap-framework-00.txt 
&=
nbsp;
Terminology:
Information Model definition tweaked, new definition for Subscriber an=
d Test Traffic.
 
Protocol Model:
Added a high=
-level protocol model  
 
Privacy considerations:
A substantial new section. It may be better removing it and securi=
ty considerations into a new draft about threats and how to alleviate them?=

 
L=
ooking forward to the discussions!
Phil, A=
l, Paul, Marcelo, Aamer, Trevor.
=

--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9CFD7E0EMV67UKRDdoma_--

From marcelo@it.uc3m.es  Mon Sep 23 02:21:55 2013
Return-Path: 
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 872F211E8192 for ; Mon, 23 Sep 2013 02:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.349
X-Spam-Level: 
X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 BYVIvI1sto60 for ; Mon, 23 Sep 2013 02:21:48 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3F311E8186 for ; Mon, 23 Sep 2013 02:21:29 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2CCB989466D for ; Mon, 23 Sep 2013 11:21:27 +0200 (CEST)
X-uc3m-safe: yes
Received: from [163.117.203.127] (unknown [163.117.203.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id F0553890EF9 for ; Mon, 23 Sep 2013 11:21:26 +0200 (CEST)
Message-ID: <52400816.7070900@it.uc3m.es>
Date: Mon, 23 Sep 2013 11:21:26 +0200
From: marcelo bagnulo braun 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: lmap@ietf.org
References:  <9904FB1B0159DA42B0B887B7FA8119CA128E22FE@AZ-FFEXMB04.global.avaya.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Mon, 23 Sep 2013 11:21:27 +0200 (CEST)
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20168.006
X-TM-AS-Result: No--24.508-7.0-31-1
X-imss-scan-details: No--24.508-7.0-31-1
Subject: Re: [lmap] Merged framework draft
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 09:21:55 -0000

agree

El 23/09/13 11:04, philip.eardley@bt.com escribió:
>
> Personally I think it is
>
> *From:*Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> *Sent:* 23 September 2013 09:56
> *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org
> *Subject:* RE: Merged framework draft
>
> Hi,
>
> Thanks to Philip and all the authors for the good work.
>
> We need however to be a little more aggressive. The WG charter 
> includes the following milestone.
>
> Sep 2013
>
> 	
>
> Initial WG I-D for the LMAP Framework including terminology
>
> According to the authors – is this I-D in good enough shape for 
> becoming the initial WG I-D? If the authors say ‘yes’ the chairs can 
> ask on the WG list about consensus on this issue.
>
> We have a similar milestone for the Use Cases document.
>
> Regards,
>
> Dan
>
> *From:*lmap-bounces@ietf.org  
> [mailto:lmap-bounces@ietf.org] *On Behalf Of *philip.eardley@bt.com 
> 
> *Sent:* Monday, September 23, 2013 11:47 AM
> *To:* lmap@ietf.org 
> *Subject:* [lmap] Merged framework draft
>
> We have been working on a framework draft that merges the previous 2 
> framework drafts & the terminology draft, as well as including various 
> things that have been discussed on the list since.
>
> Our plan is to produce an update before the Vancouver deadline. We 
> have a few things that we’re planning to work on, but we wanted to get 
> it out in order to get everyone else’s comments.
>
> http://www.ietf.org/id/draft-folks-lmap-framework-00.txt
>
> Terminology:
>
> Information Model definition tweaked, new definition for Subscriber 
> and Test Traffic.
>
> Protocol Model:
>
> Added a high-level protocol model
>
> Privacy considerations:
>
> A substantial new section. It may be better removing it and security 
> considerations into a new draft about threats and how to alleviate them?
>
> Looking forward to the discussions!
>
> Phil, Al, Paul, Marcelo, Aamer, Trevor.
>
>
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap


From trevor.burbridge@bt.com  Mon Sep 23 04:03:55 2013
Return-Path: 
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 2583E21F9C47 for ; Mon, 23 Sep 2013 04:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.884
X-Spam-Level: 
X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1]
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 CnARpUaZtxzZ for ; Mon, 23 Sep 2013 04:03:50 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 96F7121F9AA8 for ; Mon, 23 Sep 2013 04:03:49 -0700 (PDT)
Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 23 Sep 2013 12:03:42 +0100
Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.193]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 23 Sep 2013 12:03:42 +0100
From: 
To: , 
Date: Mon, 23 Sep 2013 12:03:40 +0100
Thread-Topic: [lmap] Merged framework draft
Thread-Index: Ac64PlvJ85+HBdwnSZidzMfN/rJmZgADesjQ
Message-ID: 
References:  <9904FB1B0159DA42B0B887B7FA8119CA128E22FE@AZ-FFEXMB04.global.avaya.com>  <52400816.7070900@it.uc3m.es>
In-Reply-To: <52400816.7070900@it.uc3m.es>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [lmap] Merged framework draft
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 11:03:55 -0000

Also for myself. Fairly comprehensive and captures all of the major points =
that have been discussed/agreed so far.

Trevor.

>-----Original Message-----
>From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of
>marcelo bagnulo braun
>Sent: 23 September 2013 10:21
>To: lmap@ietf.org
>Subject: Re: [lmap] Merged framework draft
>
>agree
>
>El 23/09/13 11:04, philip.eardley@bt.com escribi=F3:
>>
>> Personally I think it is
>>
>> *From:*Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
>> *Sent:* 23 September 2013 09:56
>> *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org
>> *Subject:* RE: Merged framework draft
>>
>> Hi,
>>
>> Thanks to Philip and all the authors for the good work.
>>
>> We need however to be a little more aggressive. The WG charter
>> includes the following milestone.
>>
>> Sep 2013
>>
>>
>>
>> Initial WG I-D for the LMAP Framework including terminology
>>
>> According to the authors - is this I-D in good enough shape for
>> becoming the initial WG I-D? If the authors say 'yes' the chairs can
>> ask on the WG list about consensus on this issue.
>>
>> We have a similar milestone for the Use Cases document.
>>
>> Regards,
>>
>> Dan
>>
>> *From:*lmap-bounces@ietf.org 
>> [mailto:lmap-bounces@ietf.org] *On Behalf Of *philip.eardley@bt.com
>> 
>> *Sent:* Monday, September 23, 2013 11:47 AM
>> *To:* lmap@ietf.org 
>> *Subject:* [lmap] Merged framework draft
>>
>> We have been working on a framework draft that merges the previous 2
>> framework drafts & the terminology draft, as well as including various
>> things that have been discussed on the list since.
>>
>> Our plan is to produce an update before the Vancouver deadline. We
>> have a few things that we're planning to work on, but we wanted to get
>> it out in order to get everyone else's comments.
>>
>> http://www.ietf.org/id/draft-folks-lmap-framework-00.txt
>>
>> Terminology:
>>
>> Information Model definition tweaked, new definition for Subscriber
>> and Test Traffic.
>>
>> Protocol Model:
>>
>> Added a high-level protocol model
>>
>> Privacy considerations:
>>
>> A substantial new section. It may be better removing it and security
>> considerations into a new draft about threats and how to alleviate them?
>>
>> Looking forward to the discussions!
>>
>> Phil, Al, Paul, Marcelo, Aamer, Trevor.
>>
>>
>>
>> _______________________________________________
>> lmap mailing list
>> lmap@ietf.org
>> https://www.ietf.org/mailman/listinfo/lmap
>
>_______________________________________________
>lmap mailing list
>lmap@ietf.org
>https://www.ietf.org/mailman/listinfo/lmap

From acmorton@att.com  Mon Sep 23 05:32:55 2013
Return-Path: 
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 095FF21F99F8 for ; Mon, 23 Sep 2013 05:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.555
X-Spam-Level: 
X-Spam-Status: No, score=-105.555 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 cLEXHqqReVyg for ; Mon, 23 Sep 2013 05:32:47 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 7898E21F8EB5 for ; Mon, 23 Sep 2013 05:32:46 -0700 (PDT)
Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id A076E12075C; Mon, 23 Sep 2013 08:32:43 -0400 (EDT)
Received: from njfpsrvexg1.research.att.com (njfpsrvexg1.research.att.com [135.207.177.20]) by mail-green.research.att.com (Postfix) with ESMTP id E7F2DE004A; Mon, 23 Sep 2013 08:32:05 -0400 (EDT)
Received: from concierge.research.att.com (135.207.255.39) by njfpsrvexg1.research.att.com (135.207.177.20) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 23 Sep 2013 08:32:45 -0400
Received: from NJFPSRVEXG8.research.att.com ([fe80:0000:0000:0000:cdea:b3f6:62.250.24.65]) by concierge.research.att.com ([135.207.24.83]) with mapi; Mon, 23 Sep 2013 08:32:26 -0400
From: "MORTON, ALFRED C (AL)" 
To: "trevor.burbridge@bt.com" , "marcelo@it.uc3m.es" , "lmap@ietf.org" 
Date: Mon, 23 Sep 2013 08:32:25 -0400
Thread-Topic: [lmap] Merged framework draft
Thread-Index: Ac64PlvJ85+HBdwnSZidzMfN/rJmZgADesjQAALeSBA=
Message-ID: <2845723087023D4CB5114223779FA9C8AAEE8AE0@njfpsrvexg8.research.att.com>
References:  <9904FB1B0159DA42B0B887B7FA8119CA128E22FE@AZ-FFEXMB04.global.avaya.com>  <52400816.7070900@it.uc3m.es> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [lmap] Merged framework draft
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 12:32:55 -0000

I also think this memo is worthy of "initial wg I-D".

And, same as many WG participants I'm sure,=20
there's a bit of text I'd like to tweak=20
(especially lines I contributed).

Al

> -----Original Message-----
> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of
> trevor.burbridge@bt.com
> Sent: Monday, September 23, 2013 7:04 AM
> To: marcelo@it.uc3m.es; lmap@ietf.org
> Subject: Re: [lmap] Merged framework draft
>=20
> Also for myself. Fairly comprehensive and captures all of the major point=
s
> that have been discussed/agreed so far.
>=20
> Trevor.
>=20
> >-----Original Message-----
> >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of
> >marcelo bagnulo braun
> >Sent: 23 September 2013 10:21
> >To: lmap@ietf.org
> >Subject: Re: [lmap] Merged framework draft
> >
> >agree
> >
> >El 23/09/13 11:04, philip.eardley@bt.com escribi=F3:
> >>
> >> Personally I think it is
> >>
> >> *From:*Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> >> *Sent:* 23 September 2013 09:56
> >> *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org
> >> *Subject:* RE: Merged framework draft
> >>
> >> Hi,
> >>
> >> Thanks to Philip and all the authors for the good work.
> >>
> >> We need however to be a little more aggressive. The WG charter
> >> includes the following milestone.
> >>
> >> Sep 2013
> >>
> >>
> >>
> >> Initial WG I-D for the LMAP Framework including terminology
> >>
> >> According to the authors - is this I-D in good enough shape for
> >> becoming the initial WG I-D? If the authors say 'yes' the chairs can
> >> ask on the WG list about consensus on this issue.
> >>
> >> We have a similar milestone for the Use Cases document.
> >>
> >> Regards,
> >>
> >> Dan
> >>
> >> *From:*lmap-bounces@ietf.org 
> >> [mailto:lmap-bounces@ietf.org] *On Behalf Of *philip.eardley@bt.com
> >> 
> >> *Sent:* Monday, September 23, 2013 11:47 AM
> >> *To:* lmap@ietf.org 
> >> *Subject:* [lmap] Merged framework draft
> >>
> >> We have been working on a framework draft that merges the previous 2
> >> framework drafts & the terminology draft, as well as including various
> >> things that have been discussed on the list since.
> >>
> >> Our plan is to produce an update before the Vancouver deadline. We
> >> have a few things that we're planning to work on, but we wanted to get
> >> it out in order to get everyone else's comments.
> >>
> >> http://www.ietf.org/id/draft-folks-lmap-framework-00.txt
> >>
> >> Terminology:
> >>
> >> Information Model definition tweaked, new definition for Subscriber
> >> and Test Traffic.
> >>
> >> Protocol Model:
> >>
> >> Added a high-level protocol model
> >>
> >> Privacy considerations:
> >>
> >> A substantial new section. It may be better removing it and security
> >> considerations into a new draft about threats and how to alleviate
> them?
> >>
> >> Looking forward to the discussions!
> >>
> >> Phil, Al, Paul, Marcelo, Aamer, Trevor.
> >>
> >>
> >>
> >> _______________________________________________
> >> lmap mailing list
> >> lmap@ietf.org
> >> https://www.ietf.org/mailman/listinfo/lmap
> >
> >_______________________________________________
> >lmap mailing list
> >lmap@ietf.org
> >https://www.ietf.org/mailman/listinfo/lmap
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap

From trammell@tik.ee.ethz.ch  Mon Sep 23 05:39:58 2013
Return-Path: 
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 C0AD621F9E33 for ; Mon, 23 Sep 2013 05:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4]
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 czPrXbP5Lzbi for ; Mon, 23 Sep 2013 05:39:53 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3481F21F9E46 for ; Mon, 23 Sep 2013 05:39:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DB1A7D9304; Mon, 23 Sep 2013 14:39:51 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VgFYxZgtz7Zb; Mon, 23 Sep 2013 14:39:51 +0200 (MEST)
Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A242BD9300; Mon, 23 Sep 2013 14:39:51 +0200 (MEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_AA2B5B3C-A4D4-4B73-8981-A44B27086635"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Brian Trammell 
In-Reply-To: <2845723087023D4CB5114223779FA9C8AAEE8AE0@njfpsrvexg8.research.att.com>
Date: Mon, 23 Sep 2013 14:39:50 +0200
Message-Id: <0C803E9B-C675-4C7F-96C0-7A56340BCFA6@tik.ee.ethz.ch>
References:  <9904FB1B0159DA42B0B887B7FA8119CA128E22FE@AZ-FFEXMB04.global.avaya.com>  <52400816.7070900@it.uc3m.es>  <2845723087023D4CB5114223779FA9C8AAEE8AE0@njfpsrvexg8.research.att.com>
To: "lmap@ietf.org" 
X-Mailer: Apple Mail (2.1508)
Cc: marcelo@it.uc3m.es, trevor.burbridge@bt.com, "MORTON, ALFRED C \(AL\)" 
Subject: Re: [lmap] Merged framework draft
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 12:39:59 -0000

--Apple-Mail=_AA2B5B3C-A4D4-4B73-8981-A44B27086635
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi, all,

I have not had a chance to do a detailed review of the draft, and =
there's IMO still the issue of capability advertisement/exchange to =
tackle, but this revision of the document appears ready for WG adoption =
on an initial review.

Cheers,

Brian


On 23 Sep 2013, at 14:32 , "MORTON, ALFRED C (AL)"  =
wrote:

> I also think this memo is worthy of "initial wg I-D".
>=20
> And, same as many WG participants I'm sure,=20
> there's a bit of text I'd like to tweak=20
> (especially lines I contributed).
>=20
> Al
>=20
>> -----Original Message-----
>> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf =
Of
>> trevor.burbridge@bt.com
>> Sent: Monday, September 23, 2013 7:04 AM
>> To: marcelo@it.uc3m.es; lmap@ietf.org
>> Subject: Re: [lmap] Merged framework draft
>>=20
>> Also for myself. Fairly comprehensive and captures all of the major =
points
>> that have been discussed/agreed so far.
>>=20
>> Trevor.
>>=20
>>> -----Original Message-----
>>> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf =
Of
>>> marcelo bagnulo braun
>>> Sent: 23 September 2013 10:21
>>> To: lmap@ietf.org
>>> Subject: Re: [lmap] Merged framework draft
>>>=20
>>> agree
>>>=20
>>> El 23/09/13 11:04, philip.eardley@bt.com escribi=F3:
>>>>=20
>>>> Personally I think it is
>>>>=20
>>>> *From:*Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
>>>> *Sent:* 23 September 2013 09:56
>>>> *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org
>>>> *Subject:* RE: Merged framework draft
>>>>=20
>>>> Hi,
>>>>=20
>>>> Thanks to Philip and all the authors for the good work.
>>>>=20
>>>> We need however to be a little more aggressive. The WG charter
>>>> includes the following milestone.
>>>>=20
>>>> Sep 2013
>>>>=20
>>>>=20
>>>>=20
>>>> Initial WG I-D for the LMAP Framework including terminology
>>>>=20
>>>> According to the authors - is this I-D in good enough shape for
>>>> becoming the initial WG I-D? If the authors say 'yes' the chairs =
can
>>>> ask on the WG list about consensus on this issue.
>>>>=20
>>>> We have a similar milestone for the Use Cases document.
>>>>=20
>>>> Regards,
>>>>=20
>>>> Dan
>>>>=20
>>>> *From:*lmap-bounces@ietf.org 
>>>> [mailto:lmap-bounces@ietf.org] *On Behalf Of *philip.eardley@bt.com
>>>> 
>>>> *Sent:* Monday, September 23, 2013 11:47 AM
>>>> *To:* lmap@ietf.org 
>>>> *Subject:* [lmap] Merged framework draft
>>>>=20
>>>> We have been working on a framework draft that merges the previous =
2
>>>> framework drafts & the terminology draft, as well as including =
various
>>>> things that have been discussed on the list since.
>>>>=20
>>>> Our plan is to produce an update before the Vancouver deadline. We
>>>> have a few things that we're planning to work on, but we wanted to =
get
>>>> it out in order to get everyone else's comments.
>>>>=20
>>>> http://www.ietf.org/id/draft-folks-lmap-framework-00.txt
>>>>=20
>>>> Terminology:
>>>>=20
>>>> Information Model definition tweaked, new definition for Subscriber
>>>> and Test Traffic.
>>>>=20
>>>> Protocol Model:
>>>>=20
>>>> Added a high-level protocol model
>>>>=20
>>>> Privacy considerations:
>>>>=20
>>>> A substantial new section. It may be better removing it and =
security
>>>> considerations into a new draft about threats and how to alleviate
>> them?
>>>>=20
>>>> Looking forward to the discussions!
>>>>=20
>>>> Phil, Al, Paul, Marcelo, Aamer, Trevor.
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> lmap mailing list
>>>> lmap@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lmap
>>>=20
>>> _______________________________________________
>>> lmap mailing list
>>> lmap@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lmap
>> _______________________________________________
>> lmap mailing list
>> lmap@ietf.org
>> https://www.ietf.org/mailman/listinfo/lmap
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap


--Apple-Mail=_AA2B5B3C-A4D4-4B73-8981-A44B27086635
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSQDaXAAoJENt3nsOmbNJcOWwH/0Ta++Gvph/RsryYi93AXvV+
4VVjTPCHvgsl/h1u/EEp6QH93xPzSopxQkGWc9PVTaq3uwo+PCdiAjW4KaUKGxfr
T0vLKNcpr94jNCblTL8o3IbrC1qzcRinSpW8Hgzg/vlaYf37TQXjhi6Fo2R6Q+jY
3WmrWNbGotj4i3sTnmVOgxxWF8LMk14J9fpJqCOYEm9RKPvqQTuXMFlsL7FBd2nU
jWvcWSp38tWQ73WRMp3fwoB75yHtxzKz5E5T6Qw1JkR3qAW/2CC5ysLxqsjd3Rhc
v7d5d+ywLkqQgLmc2KuwTgSciAPMJMg+v4K5dwUU48vujy2TQRoZDab5xS2bONw=
=cSLj
-----END PGP SIGNATURE-----

--Apple-Mail=_AA2B5B3C-A4D4-4B73-8981-A44B27086635--

From bs7652@att.com  Mon Sep 23 06:44:20 2013
Return-Path: 
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 F0E6B21F9F88 for ; Mon, 23 Sep 2013 06:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.677
X-Spam-Level: 
X-Spam-Status: No, score=-6.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 MolGSLCF6yf6 for ; Mon, 23 Sep 2013 06:44:14 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78821F9F2D for ; Mon, 23 Sep 2013 06:44:13 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id da540425.0.5206175.00-248.14298057.nbfkord-smmo06.seg.att.com (envelope-from );  Mon, 23 Sep 2013 13:44:13 +0000 (UTC)
X-MXL-Hash: 524045ad57f5038c-064bb338618dcdb9f12c361afb28ee92155b5534
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8NDiC5J019705; Mon, 23 Sep 2013 09:44:12 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8NDi4Gc019535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Sep 2013 09:44:09 -0400
Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (GAALPA1MSGHUB9F.itservices.sbc.com [130.8.36.92]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 23 Sep 2013 13:43:53 GMT
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.03.0158.001; Mon, 23 Sep 2013 09:43:53 -0400
From: "STARK, BARBARA H" 
To: Juergen Schoenwaelder 
Thread-Topic: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
Thread-Index: AQHOtEBmosHnAD2uTEyRx3kEALw3KJnLcBFggAF4H4CAACIwoIAAszgAgAWZWfA=
Date: Mon, 23 Sep 2013 13:43:53 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E611303755B2@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA128DC22D@AZ-FFEXMB04.global.avaya.com>   <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> <20130918072600.GA46326@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130919070653.GA51566@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303729CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130919195041.GA1760@elstar.local>
In-Reply-To: <20130919195041.GA1760@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.217.69]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
X-AnalysisOut: [v=2.0 cv=WrCcx6jv c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=H4hcY09CfawA:10 a=l4EBnxoveaQA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=Lb5Mp4LI0xsA:10 a=1veTca_WZ6MKREVjbnsA:9 a=CjuIK1]
X-AnalysisOut: [q_8ugA:10]
Cc: "lmap@ietf.org" 
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 13:44:21 -0000

> > The Control Protocol MUST include support for all Controller-MA element=
s
> > of the Information Model. This includes support for all Measurement
> > Methods identified in [ippm registry].

> This is IMHO non-sense. Requiring support for _all_ measurements methods
> registered is not meaningful. This MUST is not implementable as the regis=
try
> can change any time (nor is the implementation of all measurement methods
> at a given snapshot in time necessarily meaningful).

Interesting. When I design data models or databases and expect an important=
 input (e.g., the ippm registry) to change relatively often, I use a "data-=
driven" design, rather than a "hard-coded" design. That is, I use pointers =
to the input, so that whenever the input changes, my data model or database=
 can automatically change with it. The hard-coded approach would only provi=
de for a mapping of the input up to the given snapshot in time. And not eve=
n including the full set of Measurement Methods listed in the registry at a=
 given snapshot in time strikes me as undesirable, since that means the dat=
a model designers are overriding the recommendations of ippm as to what Mea=
surement Methods (and their configuration and reporting information) need t=
o be standardized. I thought there was agreement that ippm was to be truste=
d to create this registry and that lmap would simply take that as input, wi=
thout further trying to restrict or edit the registry info. But perhaps I w=
as mistaken. Personally, since my expertise lies in operations and not meas=
urements, I will not be presuming to know better than the ippm people who c=
reate the registry.=20

Well, in any case, this is a criterion I will use when making recommendatio=
ns to my employer, and a design choice I will make in my external-to-IETF e=
fforts. Hard-coded designs tend to be a little bit cheaper in the near-term=
, but much more expensive in the long-term. I've never seen people regretti=
ng data-driven designs that have been in the field for 5 or 10 or 20 years.=
 I've often seen people regret hard-coding -- sometimes within a year.

But I have no problem with it not being reflected in any lmap document.
Barbara

From aakhter@cisco.com  Mon Sep 23 07:00:24 2013
Return-Path: 
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 AC5E721F89EB for ; Mon, 23 Sep 2013 07:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 vByyenxKYJkX for ; Mon, 23 Sep 2013 07:00:08 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2155921F9FE5 for ; Mon, 23 Sep 2013 07:00:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13074; q=dns/txt; s=iport; t=1379944808; x=1381154408; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=SXB6BS9QRNcPS16EmgD5kMcuVJds+zu2a8ZHPB7v+pk=; b=Mmt0G7UiB5T2OuM4K+4FMpz5XRBQZRGbLsaGLgCjjE2sgzjfjvKyHjWD W9piB+7JVoUGIeZBu3S8pYz6zWE4lSBj2FeyZKBl7w9DfL8lCl4/FT8XW 0ihg/TMD7T9vAhEqUjwNaakQ0JXPCau3OpaZPGowbE3dHcGeW0MF2d3Qo A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFALxIQFKtJXHA/2dsb2JhbABZgkNEOFLBMYEhFnSCJQEBAQQtXAIBCBEEAQELHQcyFAkIAQEEARIIAYd8DLs8jzQ3AYMegQADlB+VVIMkgio
X-IronPort-AV: E=Sophos;i="4.90,962,1371081600";  d="scan'208,217";a="263090053"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 23 Sep 2013 14:00:07 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8NE07V5016193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 14:00:07 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 09:00:06 -0500
From: "Aamer Akhter (aakhter)" 
To: "Romascanu, Dan (Dan)" , "philip.eardley@bt.com" , "lmap@ietf.org" 
Thread-Topic: Merged framework draft
Thread-Index: Ac64OWpJZzk6ojk7TGeVOttUV8E7gAAAODBwAAqpQ/A=
Date: Mon, 23 Sep 2013 14:00:06 +0000
Message-ID: <75C0E47A1889264493A2DCB2869AC0963358A5EB@xmb-rcd-x15.cisco.com>
References:  <9904FB1B0159DA42B0B887B7FA8119CA128E22FE@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128E22FE@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.25.21]
Content-Type: multipart/alternative; boundary="_000_75C0E47A1889264493A2DCB2869AC0963358A5EBxmbrcdx15ciscoc_"
MIME-Version: 1.0
Subject: Re: [lmap] Merged framework draft
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 14:00:25 -0000

--_000_75C0E47A1889264493A2DCB2869AC0963358A5EBxmbrcdx15ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi  Dan,

Yes. I personally feel it's a good candidate for the initial WG I-D. Of cou=
rse there are some 'tweaks' we'd all like to shape in.

aa

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Rom=
ascanu, Dan (Dan)
Sent: Monday, September 23, 2013 4:56 AM
To: philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Merged framework draft

Hi,

Thanks to Philip and all the authors for the good work.

We need however to be a little more aggressive. The WG charter includes the=
 following milestone.

Sep 2013

Initial WG I-D for the LMAP Framework including terminology


According to the authors - is this I-D in good enough shape for becoming th=
e initial WG I-D? If the authors say 'yes' the chairs can ask on the WG lis=
t about consensus on this issue.

We have a similar milestone for the Use Cases document.

Regards,

Dan



From: lmap-bounces@ietf.org [mailto:lmap-boun=
ces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, September 23, 2013 11:47 AM
To: lmap@ietf.org
Subject: [lmap] Merged framework draft

We have been working on a framework draft that merges the previous 2 framew=
ork drafts & the terminology draft, as well as including various things tha=
t have been discussed on the list since.
Our plan is to produce an update before the Vancouver deadline. We have a f=
ew things that we're planning to work on, but we wanted to get it out in or=
der to get everyone else's comments.
http://www.ietf.org/id/draft-folks-lmap-framework-00.txt

Terminology:
Information Model definition tweaked, new definition for Subscriber and Tes=
t Traffic.

Protocol Model:
Added a high-level protocol model

Privacy considerations:
A substantial new section. It may be better removing it and security consid=
erations into a new draft about threats and how to alleviate them?

Looking forward to the discussions!
Phil, Al, Paul, Marcelo, Aamer, Trevor.

--_000_75C0E47A1889264493A2DCB2869AC0963358A5EBxmbrcdx15ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi  Dan, 


 


Yes. I personally feel=
 it’s a good candidate for the initial WG I-D. Of course there are so=
me ‘tweaks’ we’d all like to shape in.<=
/p>

 


aa

 






From: lmap-bounces@ietf.org [mailto:lmap-boun=
ces@ietf.org]
On Behalf Of Romascanu, Dan (Dan)

Sent: Monday, September 23, 2013 4:56 AM

To: philip.eardley@bt.com; lmap@ietf.org

Subject: Re: [lmap] Merged framework draft






 


Hi,<=
/p>

 


Thanks to Philip and a=
ll the authors for the good work.



 


We need however to be =
a little more aggressive. The WG charter includes the following milestone.



 


Sep 2013 
Initial WG I-D for th=
e LMAP Framework including terminology






Sep 2013 





Initial WG I-D for the LMAP Framework including terminolog=
y








 


According to the autho=
rs – is this I-D in good enough shape for becoming the initial WG I-D=
? If the authors say ‘yes’ the chairs can ask on the WG list ab=
out consensus on this issue.



 


We have a similar mile=
stone for the Use Cases document.



 


Regards,


 


Dan<=
/p>

 


 


 








From:
lmap-bounces@ie=
tf.org [mailto:lmap-bounces@ietf.org]
On Behalf Of philip.eardley@bt.com

Sent: Monday, September 23, 2013 11:47 AM

To: lmap@ietf.or=
g

Subject: [lmap] Merged framework draft






 


We have been working on a =
framework draft that merges the previous 2 framework drafts & the termi=
nology draft, as well as including various things that have been
 discussed on the list since. 


Our plan is to produce an =
update before the Vancouver deadline. We have a few things that we’re=
 planning to work on, but we wanted to get it out in order to get
 everyone else’s comments.


http://www.ietf.org/id/draft-fol=
ks-lmap-framework-00.txt



 

Terminology:


Information Model definiti=
on tweaked, new definition for Subscriber and Test Traffic.


 

Protocol Model:=



Added a high-level protoco=
l model  


 

Privacy considerations:


A substantial new section.=
 It may be better removing it and security considerations into a new draft =
about threats and how to alleviate them?


 

Looking forward to the dis=
cussions!


Phil, Al, Paul, Marcelo, A=
amer, Trevor.








--_000_75C0E47A1889264493A2DCB2869AC0963358A5EBxmbrcdx15ciscoc_--

From j.schoenwaelder@jacobs-university.de  Mon Sep 23 07:53:27 2013
Return-Path: 
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 558B921F9B08 for ; Mon, 23 Sep 2013 07:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.137
X-Spam-Level: 
X-Spam-Status: No, score=-103.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 R-HJ68Z6Jr2q for ; Mon, 23 Sep 2013 07:53:22 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 29A6F21F9F08 for ; Mon, 23 Sep 2013 07:53:21 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8059F20C0E; Mon, 23 Sep 2013 16:53:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mCl9Dqh2r2Qy; Mon, 23 Sep 2013 16:53:13 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02D5720C0C; Mon, 23 Sep 2013 16:53:12 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 957B62885ADB; Mon, 23 Sep 2013 16:53:07 +0200 (CEST)
Date: Mon, 23 Sep 2013 16:53:07 +0200
From: Juergen Schoenwaelder 
To: "STARK, BARBARA H" 
Message-ID: <20130923145307.GA15555@elstar.local>
Mail-Followup-To: "STARK, BARBARA H" , "lmap@ietf.org" 
References:  <2D09D61DDFA73D4C884805CC7865E61130370CEA@GAALPA1MSGUSR9L.ITServices.sbc.com> <52393F16.3090904@it.uc3m.es> <1510BE91-4218-46A8-856C-0D83476B9436@tik.ee.ethz.ch> <20130918072600.GA46326@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130372105@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130919070653.GA51566@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303729CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130919195041.GA1760@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303755B2@GAALPA1MSGUSR9L.ITServices.sbc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303755B2@GAALPA1MSGUSR9L.ITServices.sbc.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "lmap@ietf.org" 
Subject: Re: [lmap] LMAP Framework issue #3 (take 2) Interactions between MA and Controller
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 14:53:27 -0000

Barabara,

I never wrote about hard coding something. In fact, I mentioned that the
registry is subject to changes. I do not know where I lost you.

/js

On Mon, Sep 23, 2013 at 01:43:53PM +0000, STARK, BARBARA H wrote:
> > > The Control Protocol MUST include support for all Controller-MA eleme=
nts
> > > of the Information Model. This includes support for all Measurement
> > > Methods identified in [ippm registry].
>=20
> > This is IMHO non-sense. Requiring support for _all_ measurements methods
> > registered is not meaningful. This MUST is not implementable as the reg=
istry
> > can change any time (nor is the implementation of all measurement metho=
ds
> > at a given snapshot in time necessarily meaningful).
>=20
> Interesting. When I design data models or databases and expect an importa=
nt input (e.g., the ippm registry) to change relatively often, I use a "dat=
a-driven" design, rather than a "hard-coded" design. That is, I use pointer=
s to the input, so that whenever the input changes, my data model or databa=
se can automatically change with it. The hard-coded approach would only pro=
vide for a mapping of the input up to the given snapshot in time. And not e=
ven including the full set of Measurement Methods listed in the registry at=
 a given snapshot in time strikes me as undesirable, since that means the d=
ata model designers are overriding the recommendations of ippm as to what M=
easurement Methods (and their configuration and reporting information) need=
 to be standardized. I thought there was agreement that ippm was to be trus=
ted to create this registry and that lmap would simply take that as input, =
without further trying to restrict or edit the registry info. But perhaps I=
 was mistaken. Personally, since my expertise lies in operations and not me=
asurements, I will not be presuming to know better than the ippm people who=
 create the registry.=20
>=20
> Well, in any case, this is a criterion I will use when making recommendat=
ions to my employer, and a design choice I will make in my external-to-IETF=
 efforts. Hard-coded designs tend to be a little bit cheaper in the near-te=
rm, but much more expensive in the long-term. I've never seen people regret=
ting data-driven designs that have been in the field for 5 or 10 or 20 year=
s. I've often seen people regret hard-coding -- sometimes within a year.
>=20
> But I have no problem with it not being reflected in any lmap document.
> Barbara

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From dromasca@avaya.com  Tue Sep 24 05:27:56 2013
Return-Path: 
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 0DDC721F9948 for ; Tue, 24 Sep 2013 05:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.269
X-Spam-Level: 
X-Spam-Status: No, score=-103.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 hWD8x6WpNKOS for ; Tue, 24 Sep 2013 05:27:49 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id C39A921F992A for ; Tue, 24 Sep 2013 05:27:46 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAPGDQVKHCzI1/2dsb2JhbABagmYhgQrAUIEjFnSCJwEBAxIoUQEVFRRCJgEEGxqHYwGbQoRHnH+PIINVgQADnlWLHoMkgio
X-IronPort-AV: E=Sophos;i="4.90,970,1371096000"; d="scan'208";a="29060042"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Sep 2013 08:27:44 -0400
Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Sep 2013 08:19:17 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Tue, 24 Sep 2013 14:27:42 +0200
From: "Romascanu, Dan (Dan)" 
To: "lmap@ietf.org" 
Thread-Topic: adopt draft-eardley-lmap-framework-02 as initial WG I-D for the LMAP Framework 
Thread-Index: Ac65IXbW3VC3lH2rT9STOkhiBxylfQ==
Date: Tue, 24 Sep 2013 12:27:42 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128E757D@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [lmap] adopt draft-eardley-lmap-framework-02 as initial WG I-D for the LMAP Framework
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 12:27:56 -0000

Hi,

I propose to adopt draft-eardley-lmap-framework-02 as initial WG I-D for th=
e LMAP Framework.=20

If you have any questions or concerns please send them to the WG list befor=
e Tuesday 10/1 COB.=20

Thanks and Regards,

Dan
(as chair)




From dromasca@avaya.com  Tue Sep 24 05:31:03 2013
Return-Path: 
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 91DB921F9994 for ; Tue, 24 Sep 2013 05:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.779
X-Spam-Level: 
X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 6RvrDoT6xThU for ; Tue, 24 Sep 2013 05:30:57 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id E362D21F87B7 for ; Tue, 24 Sep 2013 05:30:56 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAGCFQVKHCzI1/2dsb2JhbABagmYhgQrAUIEjFnSCJwEBAxIoUQEVFRRCJgEEGxqHYwGbQYRHnQCPIINVgQADnlWLHoMkgio
X-IronPort-AV: E=Sophos;i="4.90,970,1371096000"; d="scan'208";a="29621550"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Sep 2013 08:30:56 -0400
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Sep 2013 08:22:29 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Tue, 24 Sep 2013 14:30:54 +0200
From: "Romascanu, Dan (Dan)" 
To: "lmap@ietf.org" 
Thread-Topic: adopt draft-linsner-lmap-use-cases-03 as initial WG I-D for the LMAP Use Cases 
Thread-Index: Ac65IXbW3VC3lH2rT9STOkhiBxylfQ==
Date: Tue, 24 Sep 2013 12:30:54 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128E759F@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [lmap] adopt draft-linsner-lmap-use-cases-03 as initial WG I-D for the LMAP Use Cases
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 12:31:03 -0000

Hi,

I propose to adopt draft-linsner-lmap-use-cases-03 as initial WG I-D for th=
e LMAP Use Cases.=20

If you have any questions or concerns please send them to the WG list befor=
e Tuesday 10/1 COB.=20

Thanks and Regards,

Dan
(as chair)




From dromasca@avaya.com  Tue Sep 24 05:53:46 2013
Return-Path: 
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 36A1211E8126 for ; Tue, 24 Sep 2013 05:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.269
X-Spam-Level: 
X-Spam-Status: No, score=-103.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 3Qo1qATd9RxM for ; Tue, 24 Sep 2013 05:53:39 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id BD25911E8121 for ; Tue, 24 Sep 2013 05:53:33 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAEeKQVLGmAcV/2dsb2JhbABagmYhgQq/P4ERgSAWdIInAQEDEihRARUVFEImAQQbGodjAZs+hEecf48gg1WBAAOeVYsegySCKg
X-IronPort-AV: E=Sophos;i="4.90,970,1371096000"; d="scan'208";a="25187512"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Sep 2013 08:53:32 -0400
Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Sep 2013 08:50:30 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Tue, 24 Sep 2013 14:53:30 +0200
From: "Romascanu, Dan (Dan)" 
To: "lmap@ietf.org" 
Thread-Topic: adopt draft-folks-lmap-framework-00 as initial WG I-D for the LMAP Framework 
Thread-Index: Ac65IXbW3VC3lH2rT9STOkhiBxylfQ==
Date: Tue, 24 Sep 2013 12:53:29 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128E763B@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [lmap] adopt draft-folks-lmap-framework-00 as initial WG I-D for the LMAP Framework
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 12:53:46 -0000

Hi,

(please disregard the previous message about the LMAP Framework document)

I propose to adopt draft-folks-lmap-framework-00 as initial WG I-D for the =
LMAP Framework.=20

If you have any questions or concerns please send them to the WG list befor=
e Tuesday 10/1 COB.=20

Thanks and Regards,

Dan
(as chair)




From david.sinicrope@ericsson.com  Tue Sep 24 16:57:40 2013
Return-Path: 
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 E25CD11E8188; Tue, 24 Sep 2013 16:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level: 
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 qXiin0APHG2n; Tue, 24 Sep 2013 16:57:32 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id F3D1E11E818B; Tue, 24 Sep 2013 16:57:26 -0700 (PDT)
X-AuditID: c618062d-b7fda8e0000024c6-e5-524226e585a4
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 8B.66.09414.5E622425; Wed, 25 Sep 2013 01:57:26 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 24 Sep 2013 19:57:10 -0400
From: David Sinicrope 
To: "lmap@ietf.org" , "ippm@ietf.org" , "homenet@ietf.org" , "bmwg@ietf.org" 
Thread-Topic: Performance Measurement Liaison Response to Broadband Forum
Thread-Index: AQHOuYHIW/VhXSf3z0K0yXzmKaUdzA==
Date: Tue, 24 Sep 2013 23:57:10 +0000
Message-ID: <871EB8879748FA458598F046190628931C2708A6@eusaamb103.ericsson.se>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [147.117.188.135]
Content-Type: multipart/alternative; boundary="_000_871EB8879748FA458598F046190628931C2708A6eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonSveZmlOQwdQL7Bb9X2+yWbxfdIjF oufBO2aL5vPaFn9XXGFxYPVYsuQnk8f1pqvsAUxRXDYpqTmZZalF+nYJXBk/e7cwFVz5w1Gx /9wOpgbGC2/Yuxg5OSQETCROnpzNDGGLSVy4t56ti5GLQ0jgKKPE/f89TBDOckaJ8wv+sIFU sQF1rNu4hwUkISLQxyix9dUJFpAEs4C3RPfebWC2sICLxL+fh5hAbBEBT4mpba0sELaexPdX 08FWswioSnxd2Qs2lFfAV+L5lx9gZ3ACLeh/sZsRxGYEOun7qTVMEPPFJW49mc8EcaqAxJI9 56HOFpV4+fgfK4gtCjR/fftuqBplie9zHkHdli/R+PkZ1C5BiZMzn7BMYBSdhWTsLCRls5CU QcQNJN6fm88MYWtLLFv4GsrWl9j45SwjhG0t8fTQakZkNQsYOVYxcpQWp5blphsZbGIERuQx CTbdHYx7XloeYpTmYFES512ldyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+PEk3qRf7f/ tj0TU93C8Pi5RHLPSVmZoknKFWwJSncEImWSxJ5ZPv57av5KBed3+qZKsXPDNjWZPu7Z9/yw z+wA0bmJTUq1z/w5RPq3N4iZTGcrT9V2CHd6WsaoVixWKujA6CV4Rdiq+5Mg+89rl9/Os372 cM5Ejkr2jvYrycs7GzjENrdtUWIpzkg01GIuKk4EAKfy1+yWAgAA
Cc: Ross Callon , Jari Arkko 
Subject: [lmap] Performance Measurement Liaison Response to Broadband Forum
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 23:57:41 -0000

--_000_871EB8879748FA458598F046190628931C2708A6eusaamb103erics_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi All,
Below is a draft liaison put together with the LMAP, IPPM, Homenet and BM W=
G Chairs in response to the Broadband Forum liaisons noted below.
Please review the liaison and send comments to the relevant WG email list b=
y Monday October 1, 2013 (e.g., if a change to the LMAP response section is=
 needed, use the LMAP list to discuss your comment).  Once vetted within th=
e respective WGs, any resulting changes will be incorporated and the liaiso=
n sent to Broadband Forum.

Thanks,
Dave Sinicrope
IETF/Broadband Forum Liaison Manager

******  Begin Liaison Text  ********


Date: October xx, 2013

To:
Christophe Alter, Technical Committee Chair, Broadband Forum (christophe.al=
ter@orange.com)

From:
Dan Romascanu, IETF Large-Scale Measurement of Broadband Performance WG Cha=
ir (dromasca@avaya.com)
Jason Weil, IETF Large-Scale Measurement of Broadband Performance WG Chair =
(jason.weil@twcable.com)
Brian Trammell, IETF IP Performance Metrics WG Chair (trammell@tik.ee.ethz.=
ch)
Bill Cerveny, IETF IP Performance Metrics WG Chair (bill@wjcerveny.com)
Ray Bellis, IETF Home Networking WG Chair (mark@townsley.net)
Mark Townsley, IETF Home Networking WG Chair (ray.bellis@nominet.org.uk)
Sarah Banks, IETF Benchmarking Methodology WG Chair (sbanks@aerohive.com)
Al Morton, IETF Benchmarking Methodology WG Chair (acmorton@att.com)

CC:
David Sinicrope, IETF/Broadband Forum Liaison Manager (david.sinicrope@eric=
sson.com)
Ross Callon, IETF Internet Architecture Board (rcallon@juniper.net)
Jari Arkko, IETF Chair (jari.arkko@piuha.net)
Robin Mersh, Broadband Forum CEO (rmersh@broadband-forum.org)
Gabrielle Bingham, Broadband Forum Secretariat (gbingham@broadband-forum.or=
g)
Jason Walls, Broadband Home Working Group Co-Chair (jason@qacafe.com)
John Blackford, Broadband Home Working Group Co-Chair (john.blackford@pace.=
com)
Dave Thorne, Broadband Forum E2E Architecture WG Chair (david.j.thorne@bt.c=
om)
Dave Allan, Broadband Forum E2E Architecture WG Chair (david.i.allan@ericss=
on.com)
Sven Ooghe, Broadband Forum E2E Architecture WG Vice Chair (sven.ooghe@alca=
tel-lucent.com)
Peter Adams, Broadband Forum Operations and Network Management WG Chair (pe=
ter.adams@adtran.com)



Thank-you for your liaisons listed below and keeping the IETF in mind while=
 developing work work on Broadband Forumv(BBF) WT-304 Broadband Access Serv=
ice Attributes and Performance Metrics.

BBF Liaisons to date:
Mar 2013 - https://datatracker.ietf.org/liaison/1243/  to IETF Chair and IE=
SG
Dec 2012 - https://datatracker.ietf.org/liaison/1221/  to IPPM chairs and T=
ransport and Ops ADs
Sep 2012 - https://datatracker.ietf.org/liaison/1185/  to IETF Chair and IE=
SG
Aug 2012 - https://datatracker.ietf.org/liaison/1179/  to Ops Area Director=
s


Thank you also for your patience.  While there has been significant interes=
t in large-scale measurement of Broadband performance, formal IETF working =
groups to address major components of this topic had not been chartered unt=
il this summer.  Now that the IPPM WG has been re-chartered (to consider me=
asurement methods appropriate for large-scale measurements) and the LMAP WG=
 formed (to consider the architectural framework and operational components=
), both groups look forward to communicating with the BBF on this subject.

In addition to LMAP and IPPM, you may also want to consider BMWG and Homene=
t for some of your WT-304 efforts.  Please see the links below for all of t=
hese working groups=92 charters, scope and work plans.

LMAP (Ops and Mgmt Area) - https://datatracker.ietf.org/wg/lmap/charter/
IPPM (Transport Area) - https://datatracker.ietf.org/wg/ippm/charter/
BMWG (Ops and Mgmt Area) - https://datatracker.ietf.org/wg/bmwg/charter/
HomeNet (Internet Area) - https://datatracker.ietf.org/wg/homenet/charter/

We note that you would like to reference IETF protocols and work to satisfy=
 the requirements of your architecture.  We believe this is a good division=
 of work and scope and would be happy to cooperate along these lines.  We e=
ncourage specific communication with each of the individual working groups =
via their Chairs along the lines of their charters.  For topics that cross =
one or more WGs, please address the liaison to the Chairs of all of the rel=
evant working groups and the liaison manager from the IETF who will help di=
rect the liaison to the appropriate WG or IETF authority.

The LMAP WG is reviewing your March 2013 Liaison and notes the following re=
quests for information:

  1.  Feedback on the use of SIP to provide an inter and intra domain mecha=
nism to probe test target resource availability.
  2.  Comments on the use of DNS-SD(RFC6763) and mDNS (RFC6762) to support =
BBF's service attribute communication.
  3.  Information model development for test and report parameters

LMAP WG Response:

The LMAP WG was formed in June and held its first meeting in July of this y=
ear. Following the goals and milestones as outlined in the WG Charter that =
can be found in the above link, the WG will be focussed on finalizing Use C=
ase and Framework documents and then beginning work on the Information Mode=
l document. The Information Model was mentioned as an area of interest by t=
he BBF in the March Liaison. The LMAP WG would welcome input from the BBF a=
s it begins work on the Information Model document. For reference, the Info=
rmational Model scope as described in the LMAP WG Charter is included for r=
eference:

Information Model, the abstract definition of the information carried from =
the Controller to the MA and the information carried from the MA to the Col=
lector. It includes

   * The metric(s) that can be measured and values for its parameters such =
as the Peer MA participating in the measurement and the desired environment=
al conditions (for example, only conduct the measurement when there is no u=
ser traffic observed)

   * The schedule: when the measurement should be run and how the results s=
hould be reported (when and to which Collector)

   * The report: the metric(s) measured and when, the actual result, and su=
pporting metadata such as location. Result reports may be organized in batc=
hes or may be reported immediately, such as for an on-demand measurement.
In regards to interest of using DNS-SD and mDNS in support of service attri=
bute communication between devices within the home network, the LMAP WG wou=
ld defer this question and possible further analysis to work that is taking=
 place in the Homenet WG. It should be noted that currently the mDNS Protoc=
ol is constrained to a single link based on its use of link-local multicast=
. If the BBF would be interested in the use of mDNS and DNS-SD in a multi-s=
egmented home network, this would require new work to those protocols that =
is being discussed as part of a new Working Group. Discussion of that WG ch=
arter language is currently taking place.

In regards to the use of SIP as a inter-domain and/or intra-domain mechanis=
m for the discovery of test target (Measurement Peer in LMAP terminology) a=
vailability, this point represents communication that would take place betw=
een a Measurement Agent and a Measurement Peer. Communication requirements =
as part of a test between a MA and its measurement target (Measurement Peer=
) is currently not included as one of the work items per the LMAP charter b=
ut may be a topic of discussion for future work.

IPPM WG Response:

Please be advised that the IPPM WG has considered updates to RFC 2680 and 2=
681 in their March 2013 rechartering, but these have been deferred until it=
 is clear what impact the effort to update the framework (2330) and the eff=
ort to define a registry on the March 2013 charter will have on these updat=
es. IPPM expects that the result will be compatible with 2680 and 2681, and=
 as such developments based on these RFCs may continue as they are.

Many of the issues with 3148 raised in Question 1 of the December 2012 BBF =
liaison may be addressed by draft-ietf-ippm-model-based-metrics-00, on whic=
h work is progressing under their current charter; discussion of issues wit=
h bulk capacity measurement not addressed therein is welcome on the ippm@ie=
tf.org mailing list.

With respect to the remaining outstanding questions, the IPPM WG will take =
them as information that BBF is considering the use of 3393 and 6349 as wel=
l; IPPM is not considering updates to these at this time, so they remain a =
stable basis for further work, noting again in the latter case that draft-i=
etf-ippm-model-based-metrics-00 aims to address issues in using TCP to meas=
ure TCP bulk transfer capacity.

IPPM understands from Question 6 that 'moving up the stack', looking specif=
ically at VoIP, streaming video, and DNS resolution time, are of interest t=
o BBF. IPPM is not currently working on metrics in this area, but would cer=
tainly consider contributions thereon under its current charter, and have r=
eviewed at least one individual draft on buffered streaming video performan=
ce during the chartering discussions in March 2013.

As for the general line of these questions (especially 6), please note the =
ongoing registry effort on the IPPM charter. There are three individual dra=
fts: draft-bagnulo-ippm-new-registry, draft-bagnulo-ippm-new-registry-indep=
endent, and draft-claise-ippm-perf-metric-registry. The authors are current=
ly working on a unified approach to a performance metrics registry, with th=
e intention that the outcome be adopted for further development within the =
IPPM WG. This registry will be populated with recommended metrics for LMAP =
use cases, which would represent a consensus statement from IPPM on the met=
rics IPPM consider useful in this area. Work in this area is ongoing, and w=
e welcome commentary on the ippm@ietf.org list once t=
he unified registry document is published.

We noted that there might be interest in the identification of test referen=
ce points.  This is currently on the IPPM WG charter and we now have an ini=
tial working group document (http://datatracker.ietf.org/doc/draft-ietf-ipp=
m-lmap-path).

The IETF encourages those in the BBF who are interested in this IETF work, =
to participate and help drive the work via the relevant IETF WG email lists=
 noted above and the IETF development processes.  While formal liaison comm=
unication is necessary and beneficial, direct, active participation by inte=
rested parties is very helpful and complementary to drive the deliverables =
needed between the organizations.  Please note that access to all relevant =
IETF working groups, email lists, documents and process is open so than any=
 interested party may participate and contribute.

Likewise, the IETF would be happy to provide input and feedback on BBF rela=
ted work.  We understand the BBF is a membership organization and may restr=
ict access to its relevant works in progress.  To facilitate cooperation wi=
th the IETF, please liaise any work in progress you would like the IETF to =
consider, review, comment on, collaborate on, etc., with the understanding =
that access to the liaison and its attachments will be open and not be rest=
ricted or limited to BBF membership.

Sincerely,
LMAP, IPPM, Homenet and BMWG Chairs


******  End Liaison Text  ********

--_000_871EB8879748FA458598F046190628931C2708A6eusaamb103erics_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable










 
  Normal
  0
  
  
  
  
  false
  false
  false
  
  EN-US
  JA
  X-NONE
  
   
   
   
   
   
   
   
   
   
  
  
   
   
   
   
   
   
   
   
   
   
   
  











Hi All,



Below is a =
draft liaison put together with the LMAP, IPPM, Homenet and BM WG Chairs in=
 response to the Broadband=
 Forum liaisons noted below.


Ple=
ase review the liaison and send comments to the relevant WG email=
 list by Monday October 1, 2013 (e.g., if a change to the LMAP re=
sponse section is needed, use the LMAP list to discuss your
 comment).  Once vetted within the respective WGs, any resulting =
changes will be incorporated and the liaison sent to Broadband Forum.









Thanks,



Dave Sinicr=
ope



IETF/Broadband Forum Liaison Ma=
nager









******  Begin Liaison Text  ********















Date: October xx, 2013









To: 



Christophe Alter, T=
echnical Committee Chair, Broadband Forum (christophe=
.alter@orange.com
   
   
   
   
   
   
   
   
   
   
  
=
 


From: 








Dan Romascanu, IETF&=
nbsp;Large-Scale Measurement of Broadband Performance WG Chair (dromasca@avaya.com)


Jason Weil, IETF&nbs=
p;Large-Scale Measurement of Broadband Performance WG Chair (jason.weil@twcable.com)


Brian Trammell, IETF IP Performance Metrics WG Chair (trammell@tik.ee.ethz.ch)


Bill Cerveny, IETF IP Performance Metrics WG Chai=
r (bill@wjcerveny.com)



Ray Bellis, IETF Home Networking WG Chair (mark@townsley.net)





Ma=
rk Townsley, IETF Home Networking WG Chair (ray.bellis@nominet.org.uk<=
/a>)



Sa=
rah Banks, IETF Benchmarking Methodology WG Chair (sbanks@aerohive.com)



Al=
 Morton, IETF Benchmarking Methodology WG Chair (acmorton@att.com)








CC:






David
 Sinicrope, IETF/Broadband Forum Liaison Manager (david.sinicrope@ericsson.com)


Ross Callon, IETF Internet Architecture Board (<=
/font>rcallon@juniper.net)


Jari Arkko, IETF Cha=
ir (jari.arkko@piuha.net)<=
/p>


Robin Mersh, Broadband Forum CEO (rmersh@broadband-forum.org)=



Gabrielle Bingham, Broadband Forum Secretariat (gbingham@broadband-forum.org)=



Jason Walls, Broadband Home Working Group Co-Chair (jason@qacafe.com)

John Blackford, Broadband Home Working Group Co-=
Chair (john.blackford@pace.com)=



Dave Thorne, Broadband Forum E2E Architecture WG Chair=
 (david.j.thorne@bt.com)<=
/o:p>


Dave Allan, Broadband Forum E2E Architecture WG Chair =
(david.i.allan@ericsson.com)


Sven Ooghe, Broadband Forum E2E Architecture WG Vice C=
hair (sven.ooghe@alcatel-l=
ucent.com)


Peter Adams, Broadband Forum Operations an=
d Network Management WG Chair (pe=
ter.adams@adtran.com) 
























Thank-you for your liaisons listed below an=
d keeping the IETF in mind while developing work work on Broadband Forumv(B=
BF) WT-304 Broadband
 Access Service Attributes and Performance Metrics.  <=
/o:p>






 








BBF Liaisons to date=
:






Mar 2013 - https://datatracker.ietf=
.org/liaison/1243/  to IETF Chair and IESG






Dec 2012 - https://datatracker.ietf=
.org/liaison/1221/  to IPPM chairs and Transport and Ops ADs<=
/o:p>






Sep 2012 - https://datatracker.ietf=
.org/liaison/1185/  to IETF Chair and IESG






Aug 2012 - https://datatracker.ietf=
.org/liaison/1179/  to Ops Area Directors








 






 






Thank you also for y=
our patience.  While there has been significant interest in large-scal=
e measurement of Broadband performance, formal IETF working groups to addre=
ss major components of this topic had not been
 chartered until this summer.  Now that the IPPM WG has been re-charte=
red (to consider measurement methods appropriate for large-scale measuremen=
ts) and the LMAP WG formed (to consider the architectural framework and ope=
rational components), both groups look
 forward to communicating with the BBF on this subject.





 


In addition to LMAP =
and IPPM, you may also want to consider BMWG and Homenet for some of your W=
T-304 efforts.  Please see the links below for all of these worki=
ng groups=92 charters, scope and work plans.






 






LMAP (Ops and Mgmt A=
rea) - https:=
//datatracker.ietf.org/wg/lmap/charter/ 






IPPM (Transport Area=
) - https://d=
atatracker.ietf.org/wg/ippm/charter/ 






BMWG (Ops and Mgmt A=
rea) - https:=
//datatracker.ietf.org/wg/bmwg/charter/ 






HomeNet (Internet Ar=
ea) - http=
s://datatracker.ietf.org/wg/homenet/charter/ 





 






We note that you wou=
ld like to reference IETF protocols and work to satisfy the requirements of=
 your architecture.  We believe this is a good division of work a=
nd scope and would be happy to cooperate along these
 lines.  We encourage specific communication with each of the individu=
al working groups via their Chairs along the lines of their charters.  =
;For topics that cross one or more WGs, please address the liaison to the C=
hairs of all of the relevant working groups
 and the liaison manager from the IETF who will help direct the liaison to =
the appropriate WG or IETF authority.






 




The LMAP WG is revie=
wing your March 2013 Liaison and notes the following requests for informati=
on:










    

  1. Feedback on the =
use of SIP to provide an inter and intra domain mechanism to probe test tar=
get resource availability. 
  2. Comments on the use of DNS-SD(RF=
C6763) and mDNS (RFC6762) to support BBF's service attribute communication.=
   
  3. Information model development for test and report =
parameters 













LMAP WG Response:






 






The LMAP WG was form=
ed in June and held its first meeting in July of this year. Following the g=
oals and milestones as outlined in the WG Charter that can be found in the =
above link, the WG will be focussed on
 finalizing Use Case and Framework documents and then beginning work on the=
 Information Model document. The Information Model was mentioned as an area=
 of interest by the BBF in the March Liaison. The LMAP WG would welcome inp=
ut from the BBF as it begins work
 on the Information Model document. For reference, the Informational Model =
scope as described in the LMAP WG Charter is included for reference: <=
o:p>






In=
formation Model, the abstract definition of the information carried from th=
e Controller to the MA and the information carried from the MA to the Colle=
ctor. It includes


&n=
bsp;  * The metric(s) that can be measured and values for its paramete=
rs such as the Peer MA participating in the measurement and the desired env=
ironmental conditions (for example, only conduct the measurement when there=
 is no user traffic observed)


&n=
bsp;  * The schedule: when the measurement should be run and how the r=
esults should be reported (when and to which Collector)

&n=
bsp;  * The report: the metric(s) measured and when, the actual result=
, and supporting metadata such as location. Result reports may be organized=
 in batches or may be reported immediately, such as for an on-demand measur=
ement.








In regards to intere=
st of using DNS-SD and mDNS in support of service attribute communication b=
etween devices within the home network, the LMAP WG would defer this questi=
on and possible further analysis to work
 that is taking place in the Homenet WG. It should be noted that currently =
the mDNS Protocol is constrained to a single link based on its use of link-=
local multicast. If the BBF would be interested in the use of mDNS and DNS-=
SD in a multi-segmented home network,
 this would require new work to those protocols that is being discussed as =
part of a new Working Group. Discussion of that WG charter language is curr=
ently taking place.






 






In regards to the us=
e of SIP as a inter-domain and/or intra-domain mechanism for the discovery =
of test target (Measurement Peer in LMAP terminology) availability, this po=
int represents communication that would
 take place between a Measurement Agent and a Measurement Peer. Communicati=
on requirements as part of a test between a MA and its measurement target (=
Measurement Peer) is currently not included as one of the work items per th=
e LMAP charter but may be a topic
 of discussion for future work.






 






IPPM WG Response: &n=
bsp;








 






Please be advised th=
at the IPPM WG has considered updates to RFC 2680 and 2681 in their March 2=
013 rechartering, but these have been deferred until it is clear what impac=
t the effort to update the framework (2330)
 and the effort to define a registry on the March 2013 charter will have on=
 these updates. IPPM expects that the result will be compatible with 2680 a=
nd 2681, and as such developments based on these RFCs may continue as they =
are.






 






Many of the issues w=
ith 3148 raised in Question 1 of the December 2012 BBF liaison may be addre=
ssed by draft-ietf-ippm-model-based-metrics-00, on which work is progressin=
g under their current charter; discussion
 of issues with bulk capacity measurement not addressed therein is welcome =
on the ippm@ietf.org mailing=
 list.






 






With respect to the =
remaining outstanding questions, the IPPM WG will take them as information =
that BBF is considering the use of 3393 and 6349 as well; IPPM is not consi=
dering updates to these at this time,
 so they remain a stable basis for further work, noting again in the latter=
 case that draft-ietf-ippm-model-based-metrics-00 aims to address issues in=
 using TCP to measure TCP bulk transfer capacity.






 






IPPM understands fro=
m Question 6 that 'moving up the stack', looking specifically at VoIP, stre=
aming video, and DNS resolution time, are of interest to BBF. IPPM is not c=
urrently working on metrics in this area,
 but would certainly consider contributions thereon under its current chart=
er, and have reviewed at least one individual draft on buffered streaming v=
ideo performance during the chartering discussions in March 2013.






 






As for the general l=
ine of these questions (especially 6), please note the ongoing registry eff=
ort on the IPPM charter. There are three individual drafts: draft-bagnulo-i=
ppm-new-registry, draft-bagnulo-ippm-new-registry-independent,
 and draft-claise-ippm-perf-metric-registry. The authors are currently work=
ing on a unified approach to a performance metrics registry, with the inten=
tion that the outcome be adopted for further development within the IPPM WG=
. This registry will be populated
 with recommended metrics for LMAP use cases, which would represent a conse=
nsus statement from IPPM on the metrics IPPM consider useful in this area. =
Work in this area is ongoing, and we welcome commentary on the ippm@ietf.org list
 once the unified registry document is published.







 



We noted that there might be interest in th=
e identification of test reference points.  This is currently on the I=
PPM WG charter and we now have an initial working group document (http://data=
tracker.ietf.org/doc/draft-ietf-ippm-lmap-path). 



 




The IETF encourages =
those in the BBF who are interested in this IETF work, to participate and h=
elp drive the work via the relevant IETF WG email lists noted above and the=
 IETF development processes.  While formal
 liaison communication is necessary and beneficial, direct, active particip=
ation by interested parties is very helpful and complementary to drive the =
deliverables needed between the organizations.  Please note that acces=
s to all relevant IETF working groups,
 email lists, documents and process is open so than any interested party ma=
y participate and contribute.






 






Likewise, the IETF w=
ould be happy to provide input and feedback on BBF related work.  We u=
nderstand the BBF is a membership organization and may restrict access=
 to its relevant works in progress.  To facilitate
 cooperation with the IETF, please liaise any work in progress you would li=
ke the IETF to consider, review, comment on, collaborate on, etc., with the=
 understanding that access to the liaison and its attachments will be =
open and not be restricted or limited
 to BBF membership.


 


Sincerely, 


LMAP, IPPM, Homenet =
and BMWG Chairs 












******  End Liaison Text  ********









--_000_871EB8879748FA458598F046190628931C2708A6eusaamb103erics_--

From dromasca@avaya.com  Sun Sep 29 02:32:22 2013
Return-Path: 
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 E642D21F9FCA for ; Sun, 29 Sep 2013 02:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.003
X-Spam-Level: 
X-Spam-Status: No, score=-102.003 tagged_above=-999 required=5 tests=[AWL=-1.004, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 WN+3Jmqq-qpB for ; Sun, 29 Sep 2013 02:32:17 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 12D9521F9FC8 for ; Sun, 29 Sep 2013 02:32:15 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiwMAO/yR1KHCzI1/2dsb2JhbABWA4JmIThMBoMpqH+UTBeBCRZtB4IlAQEBAQMBAQEPERE6FwIEAQYCDQMBBAEBAwIGHQMCBBkMCxQBBgEBBQUEEwgah2QBBgWMf4xShEeKPZFuFwSBJYxfgRgWCx0Lglk1gQMDmS6FK4VuhTGBZoE+cgF+OQ
X-IronPort-AV: E=Sophos;i="4.90,1003,1371096000"; d="scan'208";a="29811547"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Sep 2013 05:32:13 -0400
Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 29 Sep 2013 05:23:37 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Sun, 29 Sep 2013 11:32:13 +0200
From: "Romascanu, Dan (Dan)" 
To: "lmap@ietf.org" 
Thread-Topic: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements
Thread-Index: AQHOuWQQkP7Iay3FVEOHkcY9oWbjJ5nceliQ
Date: Sun, 29 Sep 2013 09:32:12 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128EAA58@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.46]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Sep 2013 09:32:23 -0000

VGhpcyBpcyBvZiBpbnRlcmVzdCBmb3IgdGhlIHBhcnRpY2lwYW50cyBpbiB0aGUgTE1BTyB3b3Jr
LiANCg0KUmVnYXJkcywNCg0KRGFuDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBubXJnLWJvdW5jZXNAaXJ0Zi5vcmcgW21haWx0bzpubXJnLWJvdW5jZXNAaXJ0Zi5v
cmddIE9uIEJlaGFsZiBPZiBKdWVyZ2VuIFNjaG9lbndhZWxkZXINClNlbnQ6IFR1ZXNkYXksIFNl
cHRlbWJlciAyNCwgMjAxMyAxMToyNCBQTQ0KVG86IG5tcmdAaXJ0Zi5vcmcNClN1YmplY3Q6IFJl
OiBbbm1yZ10gMzFzdCBOTVJHIG1lZXRpbmcgLSAxc3QgTk1SRyB3b3Jrc2hvcCBvbiBsYXJnZSBz
Y2FsZSBuZXR3b3JrIG1lYXN1cmVtZW50cw0KDQpIaSwNCg0KaGVyZSBpcyBhbiB1cGRhdGUgY29u
Y2VybmluZyB0aGUgdXBjb21pbmcgTk1SRyB3b3Jrc2hvcCBjby1sb2NhdGVkIHdpdGggQ05TTSAy
MDEzLiBXZSBoYXZlIHRoZSBmb2xsb3dpbmcgdGVudGF0aXZlIGFnZW5kYToNCg0KICAwOTowMCAt
IFJJUEUgQXRsYXMgSW50ZXJuYWxzIChQaGlsaXAgSG9tYnVyZykNCiAgMDk6MjAgLSBSb3V0ZXIt
YmFzZWQgYW5kIGNsaWVudC1iYXNlZCBwbGF0Zm9ybXMgZm9yIHBlcmZvcm1hbmNlDQogICAgICAg
ICAgbWVhc3VyZW1lbnQgYW5kIGNlbnNvcnNoaXAgZGV0ZWN0aW9uIChHaXVzZXBwZSBBY2V0b3Mp
DQogIDA5OjQwIC0gbVBsYW5lOiBBIFBsYXRmb3JtIGZvciBNZWFzdXJlbWVudCBJdGVyYXRpb24g
YW5kIEF1dG9tYXRpb24NCiAgICAgICAgICAoQnJpYW4gVHJhbW1lbGwpDQogIDEwOjAwIC0gRGlz
Y3Vzc2lvbg0KICAxMDozMCAtIENvZmZlZSBCcmVhaw0KICAxMTowMCAtIEEgZGlzdHJpYnV0ZWQg
bWVhc3VyZW1lbnQgbWV0aG9kIGV4cGxvaXRpbmcgcGF0aCBvdmVybGFwcGluZw0KICAgICAgICAg
IGluIGxhcmdlIHNjYWxlIG5ldHdvcmsgc3lzdGVtcyAoSG9hbmcgRGluaCkNCiAgMTE6MTUgLSBP
biBVc2luZyBQZWVyLXRvLVBlZXIgVGVjaG5vbG9neSBmb3IgRGVjZW50cmFsaXplZCBEZXRlY3Rp
b24NCiAgICAgICAgICBvZiBTZXJ2aWNlIExldmVsIEFncmVlbWVudCBWaW9sYXRpb25zIChMaXNh
bmRybyBHcmFudmlsbGUpDQogIDExOjMwIC0gQ29NSVF1YUw6IENvbGxhYm9yYXRpdmUgTWVhc3Vy
ZW1lbnQgb2YgSW50ZXJuZXQgUXVhbGl0eSBpbg0KICAgICAgICAgIExlYmFub24gKE5pY29sYXMg
Um91aGFuYSkNCiAgMTE6NDUgLSBEZXNpZ24gb2YgU2VsZi1BZGFwdGl2ZSBNb25pdG9yaW5nIFN5
c3RlbXMgRW5zdXJpbmcgUXVhbGl0eQ0KICAgICAgICAgIG9mIE1lYXN1cmVtZW50czogQSBOb3Zl
bCBBcHByb2FjaCAoSnVsaWVuIEJyb2lzaW4pDQogIDEyOjAwIC0gRGlzY3Vzc2lvbg0KICAxMjoz
MCAtIEx1bmNoIEJyZWFrDQogIDE0OjAwIC0gTWVhc3VyaW5nIEJHUCBwcm9wYWdhdGlvbiB1c2lu
ZyBjb3JyZWxhdGVkIHNwaWtlcyAoQW5kcmV5IFNhcGVnaW4pDQogIDE0OjE1IC0gRGVzaWduaW5n
IEFjdGl2ZSBNZWFzdXJlbWVudHMgZm9yIFlvdVR1YmUgKFNhYmEgQWhzYW4pDQogIDE0OjMwIC0g
RGV0ZWN0aW5nIG1pZGRsZWJveCBpbnRlcmZlcmVuY2Ugd2l0aCB0cmFjZWJveCAoRmFiaWVuIER1
Y2jDqm5lKQ0KICAxNDo0NSAtIE1lYXN1cmluZyBUQ1AgQ29ubmVjdGlvbiBFc3RhYmxpc2htZW50
IFRpbWVzIG9mIER1YWwtU3RhY2tlZA0KICAgICAgICAgIFdlYiBTZXJ2aWNlcyAoVmFpYmhhdiBC
YWpwYWkpDQogIDE1OjAwIC0gRGlzY3Vzc2lvbg0KICAxNTozMCAtIENvZmZlZSBCcmVhaw0KICAx
NjowMCAtIEh5cGVyZ3JhcGggTWluaW5nIChEaW1pdHJpIFBhcGFkaW1pdHJpb3UpDQogIDE2OjE1
IC0gRERvUyBhcyBhIFNlcnZpY2UgKEphaXIgU2FudGFubmEpDQogIDE2OjMwIC0gU29mdHdhcmUg
RGVmaW5lZCBNb25pdG9yaW5nIC0gUmVzZWFyY2ggUGxhdGZvcm0gZm9yIEhpZ2gNCiAgICAgICAg
ICBTcGVlZCBOZXR3b3JrIE1vbml0b3JpbmcgKEx1a8OhxaEgS2VrZWx5KQ0KICAxNjo0NSAtIFZv
UyAtIEEgVmFsdWUtb2YtU2VydmljZSBDb25jZXB0IGZvciBJUCBOZXR3b3JrcyAoRGFuaWVsIETD
tm5uaSkNCiAgMTc6MDAgLSBEaXNjdXNzaW9uDQogIDE3OjMwIC0gQ2xvc2luZyANCg0KRm9yIG1v
cmUgdXAtdG8tZGF0ZSBkZXRhaWxzLCBzZWUgPGh0dHA6Ly90aW55dXJsLmNvbS9wcWZrZDdlPi4g
SWYgeW91IHdhbnQgdG8gcGFydGljaXBhdGUsIHBsZWFzZSBzZW5kIG1lIGFuIGVtYWlsIHVudGls
IDIwMTMtMDktMzAgc28gdGhhdCBJIGNhbiBhZGQgeW91IHRvIHRoZSBhdHRlbmRlZXMgbGlzdC4N
Cg0KL2pzDQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5p
dmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2Ft
cHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEw
MyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpubXJnIG1haWxpbmcgbGlzdA0K
bm1yZ0BpcnRmLm9yZw0KaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ubXJn
DQo=

From vinayakh@gmail.com  Sun Sep 29 05:23:20 2013
Return-Path: 
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 2A7C421F9CF5 for ; Sun, 29 Sep 2013 05:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 vJHqaKydwhGF for ; Sun, 29 Sep 2013 05:23:19 -0700 (PDT)
Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 40FBE21F9CED for ; Sun, 29 Sep 2013 05:23:19 -0700 (PDT)
Received: by mail-pb0-f41.google.com with SMTP id rp2so4444290pbb.0 for ; Sun, 29 Sep 2013 05:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WRDkgoKMgfyiF8DEeUq/NvqCN4kX/w+haUFYehzEYt4=; b=AiKCkKO1OWIyVG8lcIbA3Z2AbA2GXH2S2gr/AuvaV2nQYfby+hkSbteySKYWSB3bPK EhCGrB5tEv6idFtz6OnA6Lp9LOTcAsmoLbWZCb9oqZSDDLdZgEdFaG2FY4WDbBIwHk1K I4vahy/4b80O9qeORf2zvavtFMydGXSylGxVJiKcu5CDuZvrUkvr1gRkIUHpsDSsK4gJ W9lo74M7IPk7WxN+54ZWff+nkyCzqvPRyV7NylOycdY8Aj28TJyD0csuR0o2iGEaX7js WKaedZvrOFvZE4iiKaNFkKYDHSBSzWEFnbE7aGSLtkpQ0DfICDcPXiVpA3cJG/ioicnL b/Yw==
MIME-Version: 1.0
X-Received: by 10.67.1.228 with SMTP id bj4mr1177485pad.157.1380457397603; Sun, 29 Sep 2013 05:23:17 -0700 (PDT)
Received: by 10.66.90.39 with HTTP; Sun, 29 Sep 2013 05:23:17 -0700 (PDT)
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128EAA58@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA128EAA58@AZ-FFEXMB04.global.avaya.com>
Date: Sun, 29 Sep 2013 17:53:17 +0530
Message-ID: 
From: Vinayak Hegde 
To: "Romascanu, Dan (Dan)" 
Content-Type: multipart/alternative; boundary=047d7b5d8d75cfd37604e784c838
Cc: "lmap@ietf.org" 
Subject: Re: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Sep 2013 12:23:20 -0000

--047d7b5d8d75cfd37604e784c838
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The presentations do look interesting. Is there going to be live feed or
video ? If not, Please do post a link to the proceedings on the list.

-- Vinayak

On Sun, Sep 29, 2013 at 3:02 PM, Romascanu, Dan (Dan) w=
rote:

> This is of interest for the participants in the LMAO work.
>
> Regards,
>
> Dan
>
>
>
>
> -----Original Message-----
> From: nmrg-bounces@irtf.org [mailto:nmrg-bounces@irtf.org] On Behalf Of
> Juergen Schoenwaelder
> Sent: Tuesday, September 24, 2013 11:24 PM
> To: nmrg@irtf.org
> Subject: Re: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale
> network measurements
>
> Hi,
>
> here is an update concerning the upcoming NMRG workshop co-located with
> CNSM 2013. We have the following tentative agenda:
>
>   09:00 - RIPE Atlas Internals (Philip Homburg)
>   09:20 - Router-based and client-based platforms for performance
>           measurement and censorship detection (Giuseppe Acetos)
>   09:40 - mPlane: A Platform for Measurement Iteration and Automation
>           (Brian Trammell)
>   10:00 - Discussion
>   10:30 - Coffee Break
>   11:00 - A distributed measurement method exploiting path overlapping
>           in large scale network systems (Hoang Dinh)
>   11:15 - On Using Peer-to-Peer Technology for Decentralized Detection
>           of Service Level Agreement Violations (Lisandro Granville)
>   11:30 - CoMIQuaL: Collaborative Measurement of Internet Quality in
>           Lebanon (Nicolas Rouhana)
>   11:45 - Design of Self-Adaptive Monitoring Systems Ensuring Quality
>           of Measurements: A Novel Approach (Julien Broisin)
>   12:00 - Discussion
>   12:30 - Lunch Break
>   14:00 - Measuring BGP propagation using correlated spikes (Andrey
> Sapegin)
>   14:15 - Designing Active Measurements for YouTube (Saba Ahsan)
>   14:30 - Detecting middlebox interference with tracebox (Fabien Duch=C3=
=AAne)
>   14:45 - Measuring TCP Connection Establishment Times of Dual-Stacked
>           Web Services (Vaibhav Bajpai)
>   15:00 - Discussion
>   15:30 - Coffee Break
>   16:00 - Hypergraph Mining (Dimitri Papadimitriou)
>   16:15 - DDoS as a Service (Jair Santanna)
>   16:30 - Software Defined Monitoring - Research Platform for High
>           Speed Network Monitoring (Luk=C3=A1=C5=A1 Kekely)
>   16:45 - VoS - A Value-of-Service Concept for IP Networks (Daniel D=C3=
=B6nni)
>   17:00 - Discussion
>   17:30 - Closing
>
> For more up-to-date details, see . If you
> want to participate, please send me an email until 2013-09-30 so that I c=
an
> add you to the attendees list.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap
>

--047d7b5d8d75cfd37604e784c838
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The presentations do look interesting. Is there =
going to be live feed or video ? If not, Please do post a link to the proce=
edings on the list.

-- Vinayak


On Sun, Sep 29, 2013 at 3:02 PM, Romascanu, =
Dan (Dan) <dromasca@avaya.com> wrote:

This is of interest for the participants in the LMAO work.



Regards,



Dan









-----Original Message-----

From: nmrg-bounces@irtf.org [m=
ailto:nmrg-bounces@irtf.org] O=
n Behalf Of Juergen Schoenwaelder

Sent: Tuesday, September 24, 2013 11:24 PM

To: nmrg@irtf.org

Subject: Re: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale ne=
twork measurements



Hi,



here is an update concerning the upcoming NMRG workshop co-located with CNS=
M 2013. We have the following tentative agenda:



=C2=A0 09:00 - RIPE Atlas Internals (Philip Homburg)

=C2=A0 09:20 - Router-based and client-based platforms for performance

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 measurement and censorship detection (Gi=
useppe Acetos)

=C2=A0 09:40 - mPlane: A Platform for Measurement Iteration and Automation<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Brian Trammell)

=C2=A0 10:00 - Discussion

=C2=A0 10:30 - Coffee Break

=C2=A0 11:00 - A distributed measurement method exploiting path overlapping=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in large scale network systems (Hoang Di=
nh)

=C2=A0 11:15 - On Using Peer-to-Peer Technology for Decentralized Detection=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of Service Level Agreement Violations (L=
isandro Granville)

=C2=A0 11:30 - CoMIQuaL: Collaborative Measurement of Internet Quality in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lebanon (Nicolas Rouhana)

=C2=A0 11:45 - Design of Self-Adaptive Monitoring Systems Ensuring Quality<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of Measurements: A Novel Approach (Julie=
n Broisin)

=C2=A0 12:00 - Discussion

=C2=A0 12:30 - Lunch Break

=C2=A0 14:00 - Measuring BGP propagation using correlated spikes (Andrey Sa=
pegin)

=C2=A0 14:15 - Designing Active Measurements for YouTube (Saba Ahsan)

=C2=A0 14:30 - Detecting middlebox interference with tracebox (Fabien Duch=
=C3=AAne)

=C2=A0 14:45 - Measuring TCP Connection Establishment Times of Dual-Stacked=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Web Services (Vaibhav Bajpai)

=C2=A0 15:00 - Discussion

=C2=A0 15:30 - Coffee Break

=C2=A0 16:00 - Hypergraph Mining (Dimitri Papadimitriou)

=C2=A0 16:15 - DDoS as a Service (Jair Santanna)

=C2=A0 16:30 - Software Defined Monitoring - Research Platform for High

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Speed Network Monitoring (Luk=C3=A1=C5=
=A1 Kekely)

=C2=A0 16:45 - VoS - A Value-of-Service Concept for IP Networks (Daniel D=
=C3=B6nni)

=C2=A0 17:00 - Discussion

=C2=A0 17:30 - Closing



For more up-to-date details, see <http://tinyurl.com/pqfkd7e>. If you want to parti=
cipate, please send me an email until 2013-09-30 so that I can add you to t=
he attendees list.




/js



--

Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University =
Bremen gGmbH

Phone: +49 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Br=
emen, Germany

Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-universi=
ty.de/>

_______________________________________________

nmrg mailing list

nmrg@irtf.org

ht=
tps://www.irtf.org/mailman/listinfo/nmrg

_______________________________________________

lmap mailing list

lmap@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/lmap





--047d7b5d8d75cfd37604e784c838--

From j.schoenwaelder@jacobs-university.de  Sun Sep 29 05:29:39 2013
Return-Path: 
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 032A121F8A67 for ; Sun, 29 Sep 2013 05:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.173
X-Spam-Level: 
X-Spam-Status: No, score=-103.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 I7-SJV7go9nD for ; Sun, 29 Sep 2013 05:29:34 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 14D2721F9228 for ; Sun, 29 Sep 2013 05:29:30 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D79E520C08; Sun, 29 Sep 2013 14:29:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2MkkHER-yYSA; Sun, 29 Sep 2013 14:29:28 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 777F020C06; Sun, 29 Sep 2013 14:29:28 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 014A12890D14; Sun, 29 Sep 2013 14:29:22 +0200 (CEST)
Date: Sun, 29 Sep 2013 14:29:22 +0200
From: Juergen Schoenwaelder 
To: Vinayak Hegde 
Message-ID: <20130929122922.GA32954@elstar.local>
Mail-Followup-To: Vinayak Hegde , "Romascanu, Dan (Dan)" , "lmap@ietf.org" 
References: <9904FB1B0159DA42B0B887B7FA8119CA128EAA58@AZ-FFEXMB04.global.avaya.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" 
Subject: Re: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Large Scale Measurement of Access network Performance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Sep 2013 12:29:39 -0000

On Sun, Sep 29, 2013 at 05:53:17PM +0530, Vinayak Hegde wrote:

> The presentations do look interesting. Is there going to be live feed or
> video ? If not, Please do post a link to the proceedings on the list.

Hi,

a live stream is unlikely but I will see whether we can produce a
recording / video of the talks.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103