From nobody Tue Mar 1 06:08:53 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F7A1A87A8 for ; Tue, 1 Mar 2016 06:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck33Q3VOgFF4 for ; Tue, 1 Mar 2016 06:08:50 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E871A8799 for ; Tue, 1 Mar 2016 06:08:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 21CAC8A4; Tue, 1 Mar 2016 15:08:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id v_OYuxzE3L1w; Tue, 1 Mar 2016 15:08:41 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 Mar 2016 15:08:48 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71C4720037; Tue, 1 Mar 2016 15:08:48 +0100 (CET) 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 gJIqJz7P-Zit; Tue, 1 Mar 2016 15:08:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 462E920036; Tue, 1 Mar 2016 15:08:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 10EB63A02B0D; Tue, 1 Mar 2016 15:08:47 +0100 (CET) Date: Tue, 1 Mar 2016 15:08:47 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20160301140846.GA28908@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F6E@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A5D9125@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F9D@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F9D@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "lmap@ietf.org" Subject: Re: [lmap] First take on the Definition of Cycle_ID X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 01 Mar 2016 14:08:52 -0000 On Mon, Feb 22, 2016 at 03:31:47PM -0500, MORTON, ALFRED C (AL) wrote: > > Yes, for me, a cycle requires repetition over time. So the framework > definition almost gets there by mentioning results that are > comparable, but it only deals with repetition *across MAs*. > In the Framework def, a repeated measurement task would have the > same Cycle-ID for every repetition, in every MA that performs the > the same repeated task, and we lose the ability to distinguish > the repetitions over time (without use of additional info, like time). Yes, the definition of the cycle-id has always been (as far as I can remember) been a unique tag for a certain measurement cycle (e.g., the FCC 2016 measurement campaign). Individual results are distinguished by time, not by the cycle id. Is there a specific reason to change that? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 1 06:13:02 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE3D1A87C4 for ; Tue, 1 Mar 2016 06:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YUN80W5fZJk for ; Tue, 1 Mar 2016 06:13:00 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A301A877C for ; Tue, 1 Mar 2016 06:13:00 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C624F14DA; Tue, 1 Mar 2016 15:12:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pchiUKWab_-Q; Tue, 1 Mar 2016 15:12:50 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 Mar 2016 15:12:58 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2536120038; Tue, 1 Mar 2016 15:12:58 +0100 (CET) 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 fDIzE-8CCtoN; Tue, 1 Mar 2016 15:12:57 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F19AA20037; Tue, 1 Mar 2016 15:12:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E6E903A02B40; Tue, 1 Mar 2016 15:12:56 +0100 (CET) Date: Tue, 1 Mar 2016 15:12:56 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160301141256.GB28908@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <4AF73AA205019A4C8A1DDD32C034631D3FF3A30F6E@NJFPSRVEXG0.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF6AEA7@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D3FF3A310C3@NJFPSRVEXG0.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF6B94C@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF6B94C@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] First take on the Definition of Cycle_ID X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 01 Mar 2016 14:13:01 -0000 On Wed, Feb 24, 2016 at 10:21:53AM +0000, Romascanu, Dan (Dan) wrote: > > Does that help? > > It helps a lot. > > The definition will need a little more text to explain and/or an example. > > Looks good to me on the user side. We need to hear also the coder side. > I do not think we should change the definition of cycle-id. Al probably wants another ID. I am still unclear why this is needed given that some larger platforms I have seen work without one (that is the timestamp of the result record is sufficient to do the right processing by the collector). Anyway, if Al feels strongly, he should work this proposal out more fully 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 nobody Wed Mar 2 07:52:28 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83A01A9027 for ; Wed, 2 Mar 2016 07:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.905 X-Spam-Level: X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGfFKcYIuRiH for ; Wed, 2 Mar 2016 07:52:25 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DAF1A8AFD for ; Wed, 2 Mar 2016 07:52:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AmAgA+C9dW/yYyC4deGQEBAQEPAQEBAYI+IStSc7okAQ2BZyOFcAKBRjgUAQEBAQEBAWQcC4RDAQEDEhteAQwJFVYmAQQbGod/AQ2bP4USmWcBCgEBARgEhhOIbi2CfoEPBZcSAY9ChESDGQyFLY5MHgEBQoNkiEwBfQEBAQ X-IPAS-Result: A2AmAgA+C9dW/yYyC4deGQEBAQEPAQEBAYI+IStSc7okAQ2BZyOFcAKBRjgUAQEBAQEBAWQcC4RDAQEDEhteAQwJFVYmAQQbGod/AQ2bP4USmWcBCgEBARgEhhOIbi2CfoEPBZcSAY9ChESDGQyFLY5MHgEBQoNkiEwBfQEBAQ X-IronPort-AV: E=Sophos;i="5.22,529,1449550800"; d="scan'208,217";a="170488282" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 02 Mar 2016 10:52:23 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 02 Mar 2016 10:52:10 -0500 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.0174.001; Wed, 2 Mar 2016 16:52:09 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: 2/22 virtual interim - draft minutes Thread-Index: AdF0m3mZwDtcWi2OSxW07Cb4Mtv/Mg== Date: Wed, 2 Mar 2016 15:52:08 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF74956@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.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF74956AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] 2/22 virtual interim - draft minutes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 02 Mar 2016 15:52:27 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF74956AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I uploaded the draft minutes of the 2/22 virtual interim at https://www.iet= f.org/proceedings/interim/2016/02/22/lmap/minutes/minutes-interim-2016-lmap= -2. Please read and let me know if anything is missing or wrongly reported. Thanks to Barbara Stark for the excellent notes that made my task trivial. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF74956AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I uploaded the draft minutes of the 2/22 virtual int= erim at https://www.ietf.org/proceedings/interim/2016/02/22/lmap/minutes/minutes-in= terim-2016-lmap-2. Please read and let me know if anything is missing o= r wrongly reported.

 

Thanks to Barbara Stark for the excellent notes that= made my task trivial.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BF74956AZFFEXMB04globa_-- From nobody Mon Mar 7 06:23:05 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264D21B419E for ; Mon, 7 Mar 2016 06:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66T7YYX651iO for ; Mon, 7 Mar 2016 06:23:02 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFE61B2F4C for ; Mon, 7 Mar 2016 06:23:02 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2APAgDY1dhW/yYyC4ddGQEBAQEHCAEBAQGCPiErIjBtBrgaghMBDYFlBRcBCYVuAoEyOBQBAQEBAQEBZBwLhEMBAQMSCxBeAQwJFVYmAQQbGod/AQ2cZIUSmUMBCgEBARgEhhmIcy2CGwtAGIEPBZcdAYVZiWmERIMZhTqOTh4BAUKDZGoBiCMBfQEBAQ X-IPAS-Result: A2APAgDY1dhW/yYyC4ddGQEBAQEHCAEBAQGCPiErIjBtBrgaghMBDYFlBRcBCYVuAoEyOBQBAQEBAQEBZBwLhEMBAQMSCxBeAQwJFVYmAQQbGod/AQ2cZIUSmUMBCgEBARgEhhmIcy2CGwtAGIEPBZcdAYVZiWmERIMZhTqOTh4BAUKDZGoBiCMBfQEBAQ X-IronPort-AV: E=Sophos;i="5.22,533,1449550800"; d="scan'208,217";a="145638917" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Mar 2016 09:22:52 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 07 Mar 2016 09:22:52 -0500 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.0174.001; Mon, 7 Mar 2016 15:22:51 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP at IETF 95 - call for agenda items Thread-Index: AdF4fNQriBtxmL2HSkaRfEoeAb5nJQ== Date: Mon, 7 Mar 2016 14:22:50 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF81DA2@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.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF81DA2AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP at IETF 95 - call for agenda items X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 14:23:04 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF81DA2AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The preliminary agenda for IETF 95 is now available at https://datatracker.= ietf.org/meeting/95/agenda.html. As things stand now, the LMAP WG will meet= on Tuesday April 5, 14:00 to 16:00, Buenos Aires time. The final agenda wi= ll be available on 3/11. Please send your proposals and requests for agenda items and meeting time t= o Jason and me. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF81DA2AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The preliminary agenda for IETF 95 is now available = at https://datatracker.ietf.org/meeting/95/agenda.html. As things stand no= w, the LMAP WG will meet on Tuesday April 5, 14:00 to 16:00, Buenos Aires t= ime. The final agenda will be available on 3/11.

 

Please send your proposals and requests for agenda i= tems and meeting time to Jason and me.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BF81DA2AZFFEXMB04globa_-- From nobody Mon Mar 7 06:37:41 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8103A1B394B for ; Mon, 7 Mar 2016 06:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJx0OYobnXwP for ; Mon, 7 Mar 2016 06:37:39 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B1B1B387B for ; Mon, 7 Mar 2016 06:37:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2APAgDY1dhW/xUHmMZdGQEBAQEHCAEBAQGCPiErIjBtBrgaghMBDYFlBRcBCYVuAoEyOBQBAQEBAQEBZBwLhEMBAQMSCxBeAQwJFVYmAQQbGod/AQ2cZIUSmUMBCgEBARgEhhmIcy2CGwtAGIEPBZcdAYVZiWmERIMZhTqOTh4BAUKDZGoBiCMBfQEBAQ X-IPAS-Result: A2APAgDY1dhW/xUHmMZdGQEBAQEHCAEBAQGCPiErIjBtBrgaghMBDYFlBRcBCYVuAoEyOBQBAQEBAQEBZBwLhEMBAQMSCxBeAQwJFVYmAQQbGod/AQ2cZIUSmUMBCgEBARgEhhmIcy2CGwtAGIEPBZcdAYVZiWmERIMZhTqOTh4BAUKDZGoBiCMBfQEBAQ X-IronPort-AV: E=Sophos;i="5.22,533,1449550800"; d="scan'208,217";a="145641151" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Mar 2016 09:37:36 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 07 Mar 2016 09:37:36 -0500 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.0174.001; Mon, 7 Mar 2016 15:37:34 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP at IETF 95 - call for agenda items Thread-Index: AdF4fuJdwskwvOZ3TYiq4MDywOkSCA== Date: Mon, 7 Mar 2016 14:37:33 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF81E05@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.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF81E05AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP at IETF 95 - call for agenda items X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 14:37:40 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF81E05AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The preliminary agenda for IETF 95 is now available at https://datatracker.= ietf.org/meeting/95/agenda.html. As things stand now, the LMAP WG will meet= on Tuesday April 5, 14:00 to 16:00, Buenos Aires time. The final agenda wi= ll be available on 3/11. Please send your proposals and requests for agenda items and meeting time t= o Jason and me. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF81E05AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The preliminary agenda for IETF 95 is now available = at https://datatracker.ietf.org/meeting/95/agenda.html. As things stand no= w, the LMAP WG will meet on Tuesday April 5, 14:00 to 16:00, Buenos Aires t= ime. The final agenda will be available on 3/11.

 

Please send your proposals and requests for agenda i= tems and meeting time to Jason and me.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BF81E05AZFFEXMB04globa_-- From nobody Fri Mar 11 23:13:56 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AABFF12DDB2; Fri, 11 Mar 2016 15:05:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230533.15028.45089.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:33 -0800 Archived-At: X-Mailman-Approved-At: Fri, 11 Mar 2016 23:13:55 -0800 Cc: alissa@cooperw.in, lmap@ietf.org Subject: [lmap] lmap - Requested session has been scheduled for IETF 95 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:34 -0000 Dear Dan Romascanu, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lmap Session 1 (2:00:00) Tuesday, Afternoon Session I 1400-1600 Room Name: Buen Ayre A size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Large-Scale Measurement of Broadband Performance Area Name: Operations and Management Area Session Requester: Dan Romascanu Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: netvc webpush stir siprec p2psip ecrit bfcpbis payload mmusic sacm clue ippm bmwg lmap mptcp netconf netmod opsarea opsawg xrblock rtcweb tcpinc avtcore Special Requests: - avoid scheduling after 4PM to allow remote participation of one of the key contributors who is located in Europe. --------------------------------------------------------- From nobody Tue Mar 15 10:08:31 2016 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 69D0912DB86 for ; Tue, 15 Mar 2016 10:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdW_5m6ahK7B for ; Tue, 15 Mar 2016 10:08:27 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C622212DB61 for ; Tue, 15 Mar 2016 10:08:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 00953764; Tue, 15 Mar 2016 18:08:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uAEPi5H04IB6; Tue, 15 Mar 2016 18:08:15 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 15 Mar 2016 18:08:23 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A653F20044; Tue, 15 Mar 2016 18:08:23 +0100 (CET) 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 F5Z3Elaj8eIo; Tue, 15 Mar 2016 18:08:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB3C320045; Tue, 15 Mar 2016 18:08:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E5FB43A3730A; Tue, 15 Mar 2016 18:08:21 +0100 (CET) Date: Tue, 15 Mar 2016 18:08:21 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160315170821.GB36069@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20160218123022.GA4899@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5D59D4@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160222120918.GA12837@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5D8DBF@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A5D8DBF@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] remove ma-task form ma-instruction-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 15 Mar 2016 17:08:29 -0000 Tim, why would a controller have to configure tasks? Why is it not sufficient to send instructions consisting of schedules (and their actions), suppressions and event definitions? What can be done by sending tasks that can't be done by also done by sending actions? /js On Mon, Feb 22, 2016 at 05:20:24PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > If a task is sent down as part of the configuration object; its meant for maintaining its ecosystem; if it sent as part of the instruction its meant for testing. The MA should indeed know what tasks it allows for what purposes. > > I didn't understand your comment - unless it is preconfigured a controller always sends down the task to the measurement agent... > > BR, > Tim > > -----Original Message----- > From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, February 22, 2016 6:09 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] remove ma-task form ma-instruction-obj > > On Thu, Feb 18, 2016 at 08:40:11PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > > > An instruction gets sent down by the controller as part of a testing cycle; a config object (which includes is general configuration or preconfiguration) - I think you are blurring the lines - Note that there are control tasks in the config so these are the "safe config" tasks. The tasks in the instruction are testing tasks so they should be "safe" for testing. I don't think we should say or enforce anything more than that. > > > > Why does it make sense for a controller to send a task as part of an instruction to the measurement agent? How does a measurement agent decide whether such a task should be accepted or rejected? > > > That being said in the BBF TR-069 implementation an MA has tasks some of which are referenced by the current instruction - these are known as test tasks by their reference to the instruction. > > Referencing tasks is just fine. The question is whether a controller should be allowed to send tasks down to the measurement agent. > > /js > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, February 18, 2016 12:30 PM > > To: lmap@ietf.org > > Subject: [lmap] remove ma-task form ma-instruction-obj > > > > Hi, > > > > while implementing things, I figured out that my daemon 'lmapd' needs, in addition to instructions received from the controller, some basic configuration information. In particular, configuration is needed about the programs that are considered measurement tasks and 'safe' to execute. (It does not make sense to allow a controller to execute /bin/sh as a measurement task for obvious reasons). This configuration information should not generally be writable. > > > > Looking at the current information model, it seems this can be very easily be achieved by removing ma-task from ma-instruction-obj into the ma-config-obj. As a consequence of this change, the ma-task-obj is not something that is exposed to be messed around with by a controller. The controller is essentially restricted to 'play' with schedules and suppressions (and we likely should add events to the ma-instruction-obj). Note that with this cange, we would not really need the recently added ma-capability-task-obj anymore since a controller can read the (for the controller read-only) configured tasks and then create schedules with actions referring to the configured tasks. > > > > In terms of implementation, what this boils down to is having a setup > > where you have in /etc/lmapd/lmapd.conf the configuration of the lmapd > > itself including the configuration of the tasks that the lmapd allows > > to be use. Instructions (locally generated or received from remote > > controllers) would go into /var/spool/lmapd/instructions/*.conf. Upon > > startup, the lmapd would read and merge all these conf files to > > produce the configuration that is executed. (There is likely a bit > > more work to support multiple controllers with proper isolation but > > that is outside the scope of LMAP for now I think.) > > > > For the YANG data model, my preferred solution would be to tag the > > leafs in the /lmap/tasks/ subtree with nacm:default-deny-write (RFC > > 6536) to document that this part of the configuration model usually is not writable for controllers. > > > > /js > > > > -- > > 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 15 12:05:12 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EC812D6DC; Tue, 15 Mar 2016 12:05:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315190507.28201.7873.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 12:05:07 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-08.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 19:05:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-08.txt Pages : 48 Date : 2016-03-15 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-information-model-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 15 12:06:16 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 358BE12DD29; Tue, 15 Mar 2016 12:06:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315190614.9814.12072.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 12:06:14 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-yang-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 19:06:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : A YANG Data Model for LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-yang-03.txt Pages : 75 Date : 2016-03-15 Abstract: This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-yang-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-yang-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 17 12:36:04 2016 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 3554E12D7F9 for ; Thu, 17 Mar 2016 12:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.593 X-Spam-Level: * X-Spam-Status: No, score=1.593 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpfUz3nCkdBk for ; Thu, 17 Mar 2016 12:36:01 -0700 (PDT) Received: from cdcipgw02.twcable.com (unknown [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 499ED12D747 for ; Thu, 17 Mar 2016 12:35:58 -0700 (PDT) X-SENDER-IP: 10.64.163.156 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.24,351,1454994000"; d="scan'208,217";a="537663309" Received: from unknown (HELO exchpapp15.corp.twcable.com) ([10.64.163.156]) by cdcipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 17 Mar 2016 15:29:35 -0400 Received: from EXCHPAPP11.corp.twcable.com (10.64.163.152) by exchpapp15.corp.twcable.com (10.64.163.156) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 17 Mar 2016 15:35:56 -0400 Received: from EXCHPAPP11.corp.twcable.com ([10.245.162.16]) by exchpapp11.corp.twcable.com ([10.245.162.16]) with mapi id 15.00.1156.000; Thu, 17 Mar 2016 15:35:55 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Thread-Topic: Draft Agenda Posted Thread-Index: AQHRgIQ5AWtnYRdag0+KpitAfLlmGA== Date: Thu, 17 Mar 2016 19:35:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22200.002 x-tm-as-result: No--37.378600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_D3107F5A50938jasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Draft Agenda Posted X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 17 Mar 2016 19:36:03 -0000 --_000_D3107F5A50938jasonweiltwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft agenda for the LMAP WG meeting taking place on Tuesday April 2nd = during IETF95 in Buenos Aires, Argentina has been uploaded and can be found= at the link below. Please let Dan or I know of any other agenda items or c= hanges needed before Monday, March 28th. https://www.ietf.org/proceedings/95/agenda/agenda-95-lmap Thanks, Jason ________________________________ 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_D3107F5A50938jasonweiltwcablecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8CE9381ADE204044B371FF5DD858038B@twcable.com> Content-Transfer-Encoding: quoted-printable
The draft agenda for the LMAP WG meeting taking place on Tuesday April= 2nd during IETF95 in Buenos Aires, Argentina has been uploaded and can be = found at the link below. Please let Dan or I know of any other agenda items= or changes needed before Monday, March 28th.


Thanks,
Jason



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-mai= l, you are hereby notified that any dissemination, distribution, copying, o= r action taken in relation to the contents of and attachments to this E-mai= l is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the = sender immediately and permanently delete the original and any copy of this= E-mail and any printout.
 --_000_D3107F5A50938jasonweiltwcablecom_-- From nobody Thu Mar 17 12:55:38 2016 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 2C70E12D6C0 for ; Thu, 17 Mar 2016 12:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8L9hSXNm3dN for ; Thu, 17 Mar 2016 12:55:35 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D4512D694 for ; Thu, 17 Mar 2016 12:54:51 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id u2HJsomo015642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Mar 2016 13:54:51 -0600 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 9E7AD1E026C; Thu, 17 Mar 2016 14:54:45 -0500 (CDT) Received: from lxdnp31k.corp.intranet (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 7C2811E0059; Thu, 17 Mar 2016 14:54:45 -0500 (CDT) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u2HJsjqO020667; Thu, 17 Mar 2016 13:54:45 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u2HJsiVs020663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Mar 2016 13:54:45 -0600 Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0195.001; Thu, 17 Mar 2016 14:54:44 -0500 From: "Bugenhagen, Michael K" To: "'Weil, Jason'" , "lmap@ietf.org" Thread-Topic: item for the Radar - RE: Draft Agenda Posted Thread-Index: AQHRgIQ5AWtnYRdag0+KpitAfLlmGJ9eCBow Date: Thu, 17 Mar 2016 19:54:44 +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.7] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E053BCF87podcwmbxex505ct_" MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: [lmap] item for the Radar - RE: Draft Agenda Posted X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 17 Mar 2016 19:55:37 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E053BCF87podcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jason, I won't make the Buenos Aires meeting, but something we need to add to = the radar is how to establish "confidence boundaries" on results, and how t= o ensure tests are accurate. All telecom test gear generally has a SOP for checking the test system is a= ccurate.... If you look at any test vendors spec's they reference ISO 910= 0, or a NIST standard on calibration and SOP's... Confidence boundary example - On a "segmented" test a portion of your err= or is going to be induced by the Path to the portion under test... = If I'm testing a circuit from Chicago to San Francisco from NY... = Maybe I want to test from NY to Chicago first to see h= ow much performance loss I have on the segment "NOT" under test... (that's= the error / confidence boundary). Items like this belong in a Standard OP procedure for each = test.... Otherwise we don't know what the confidence boundaries of the results are..= (under different test config's you need different SOP's...) ISO 9100 would say - you have to have a SOP / calibration like things to en= sure your results are both accurate, and precise.. Again -that's the international testing best practice.. so it's not creati= ng the wheel, or doing all of ISO - it's just observing their guideline to = make sure we have a confidence boundary and calibration to ensure good resu= lts like most telecom test gear do today... Like I said - just for the radar... Best regards, Mike From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason Sent: Thursday, March 17, 2016 2:36 PM To: lmap@ietf.org Subject: [lmap] Draft Agenda Posted The draft agenda for the LMAP WG meeting taking place on Tuesday April 2nd = during IETF95 in Buenos Aires, Argentina has been uploaded and can be found= at the link below. Please let Dan or I know of any other agenda items or c= hanges needed before Monday, March 28th. https://www.ietf.org/proceedings/95/agenda/agenda-95-lmap Thanks, Jason ________________________________ 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. This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. --_000_A68F3CAC468B2E48BB775ACE2DD99B5E053BCF87podcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jason,<= /p>

 <= /p>

    I won&= #8217;t make the Buenos Aires meeting, but something we need to add to the = radar is how to establish “confidence boundaries” on results, a= nd how to ensure tests are accurate.

All telecom test gear gen= erally has a SOP for checking the test system is accurate…. &nbs= p; If you look at any test vendors spec’s they reference ISO 9100, or= a NIST standard on calibration and SOP’s…

 <= /p>

Confidence boundary examp= le -   On a “segmented” test a portion of your error = is going to be induced by the Path to the portion under test…

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =             &nb= sp;            If I&= #8217;m testing a circuit from Chicago to San Francisco from NY… = ; 

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Maybe I want to test from NY to Chicago first to see h= ow much performance loss I have on the segment “NOT” under test…=  (that’s the error / confidence boundary).

 <= /p>

    &= nbsp;           Items lik= e this belong in a Standard OP procedure for each test…. 

 <= /p>

Otherwise we don’t = know what the confidence boundaries of the results are..  (under diffe= rent test config’s you need different SOP’s…)<= /span>

ISO 9100 would say –= ; you have to have a SOP / calibration like things to ensure your results a= re both accurate, and precise..

Again –that’s= the international testing best practice..  so it’s not creating= the wheel, or doing all of ISO – it’s just observing their gui= deline to make sure we have a confidence boundary and calibration to ensure good results like = most telecom test gear do today…

 <= /p>

Like I said – just = for the radar…

 <= /p>

Best regards,<= /span>

Mike

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason
Sent: Thursday, March 17, 2016 2:36 PM
To: lmap@ietf.org
Subject: [lmap] Draft Agenda Posted

 

The draft agenda for the LM= AP WG meeting taking place on Tuesday April 2nd during IETF95 in Buenos Air= es, Argentina has been uploaded and can be found at the link below. Please let Dan or I know of any other agenda items or changes = needed before Monday, March 28th.

 

 

Thanks,

Jason

 

 


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-mai= l, you are hereby notified that any dissemination, distribution, copying, o= r action taken in relation to the contents of and attachments to this E-mai= l is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the = sender immediately and permanently delete the original and any copy of this= E-mail and any printout.=

This communication is the property of CenturyLink and may contain c= onfidential or privileged information. Unauthorized use of this communicati= on is strictly prohibited and may be unlawful. If you have received this co= mmunication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communicat= ion and any attachments.
--_000_A68F3CAC468B2E48BB775ACE2DD99B5E053BCF87podcwmbxex505ct_-- From nobody Fri Mar 18 03:54:22 2016 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 EAE7612D8D9 for ; Fri, 18 Mar 2016 03:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BufJ1s1pe5lH for ; Fri, 18 Mar 2016 03:54:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D860A12D850 for ; Fri, 18 Mar 2016 03:54:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 363B922A7 for ; Fri, 18 Mar 2016 11:54:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uRjxqfi9DkU6 for ; Fri, 18 Mar 2016 11:54:06 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 18 Mar 2016 11:54:11 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 178C020044 for ; Fri, 18 Mar 2016 11:54:11 +0100 (CET) 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 ExSXjP59y1EH; Fri, 18 Mar 2016 11:54:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D58A20043; Fri, 18 Mar 2016 11:54:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4D01C3A4D90A; Fri, 18 Mar 2016 11:54:08 +0100 (CET) Date: Fri, 18 Mar 2016 11:54:07 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160318105405.GA55018@elstar.local> Mail-Followup-To: lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] some lmap result report model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 10:54:21 -0000 Hi, I am starting to implement the result reporting parts of the data and information model and I think there is room for improvements. 1) I think we report results from action and not from tasks. To make this clear, I propose to change ma-report-task-obj to ma-report-action-obj and to refer to an action name instead of a task name. Perhaps it is good to ship the name of the task the action is associated with as part of the ma-report-action-obj. 2) It is almost impossible to implement 'conflict' on a per row level. The lmap scheduler can likely track which actions were running during the execution of an action but it surely does not know the internals of the action and hence it can't know how to determine conflicts on a per row level. Likewise, the measurement action does not know how to determine what else is going on on the system and related to the lmap framework. Hence, the conflict should be reported as part of ma-report-action-obj and not as a result row property. 3) A measurement action may produce different result 'tables'. The assumption that there is a single header followed by a set of rows is too limited. We need to allow for a set of result 'tables' instead of a single one. 4) The description of ma-report-row-start-time and ma-report-row-end-time says that this timestamp is the start and the end of the action. If so, they should be reported as part of the ma-report-action-obj and not as part of the ma-report-row-obj. 5) I think the two lists of options (ma-report-task-options and ma-report-task-action-options) should be collapsed into a single combined list ma-report-action-options (since an action receives a single combined list of options). With all of this we get the following structures at the information model level: object { datetime ma-report-date; [uuid ma-report-agent-id;] [string ma-report-group-id;] [string ma-report-measurement-point;] [ma-report-action-obj ma-report-actions<0..*>;] } ma-report-obj; object { string ma-report-action-name; string ma-report-action-task-name; [ma-metric-registry-obj ma-report-action-metrics<0..*>;] [ma-option-obj ma-report-action-options<0..*>;] [string ma-report-action-tags<0..*>;] datetime ma-report-action-start-time; [datetime ma-report-action-end-time;] [string ma-report-action-conflicts<0..*>;] [ma-report-table-obj ma-report-action-result<0..*>;] } ma-report-action-obj; object { [string ma-report-task-column-labels<0..*>;] [ma-report-row-obj ma-report-task-rows<0..*>;] } ma-report-table-obj; object { data ma-report-row-value<0..*>; } ma-report-row-obj; This looks kind of implementable I think. I am not sure how efficient this is; I guess the answer is to simply convert some data into this format and to see what the result looks like and how big it gets (compared to the CSV format I am using internally). A possible concern is the fact that there is quite some redundant data; column headers hardly change and so do many fields of the ma-report-action-obj. On the other hand, having the result reports reasonably self-contained may be a plus (and given a decent secure transport, compression may take care of some of the noise). Other protocols allow to split the more static parts from the more dynamic parts but of course this adds complexity since the receiver needs to keep state in order to put things back together. /js PS: I think there should also be a way to augment in structured results in cases where more than a simple table structure is needed to report results. PS: I need to decide how data is passed internally between actions and schedules. I am most likely going to use something more compact than this on the wire format. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 21 03:47:07 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D90F12D6A4; Mon, 21 Mar 2016 03:47:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321104705.5992.27180.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 03:47:05 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-09.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 10:47:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-09.txt Pages : 49 Date : 2016-03-21 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-information-model-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 03:48:26 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 292EC12D557; Mon, 21 Mar 2016 03:48:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321104824.5968.43486.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 03:48:24 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-yang-04.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 10:48:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : A YANG Data Model for LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-yang-04.txt Pages : 72 Date : 2016-03-21 Abstract: This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-yang-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-yang-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 03:49:36 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0BB12D557; Mon, 21 Mar 2016 03:49:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321104932.6012.36074.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 03:49:32 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-restconf-02.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 10:49:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : Using RESTCONF with LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-restconf-02.txt Pages : 9 Date : 2016-03-21 Abstract: This document describes how RESTCONF can be used with a YANG data model for Large-Scale Measurement Platforms (LMAP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-restconf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-restconf-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-restconf-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 24 08:12:10 2016 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 3E46212D149 for ; Thu, 24 Mar 2016 08:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knpkvilHgXH5 for ; Thu, 24 Mar 2016 08:12:02 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CC612DB82 for ; Thu, 24 Mar 2016 07:56:47 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 6177029405223; Thu, 24 Mar 2016 14:56:43 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u2OEujLP030679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 14:56:45 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u2OEuhvH009874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Mar 2016 14:56:45 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 24 Mar 2016 10:56:40 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUg== Date: Thu, 24 Mar 2016 14:56:39 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A60F5F5US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Cc: "bs7652@att.com" , 'KEN KO' Subject: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:12:08 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A60F5F5US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Team, I noticed that the information model has support for multiple suppressions. With the current definition in the information model, it looks like there i= sn't any constraints on multiple suppression requests that can be active at= the same time. I just wanted to a confirmation on this. We used to have just 1 suppression= object in an instruction. It looks like this changed in draft-07. This actually conflicts with BBF TR-304 Section 5.2 where the text says: Suppression is the temporary cessation of all or a subset of measurement-re= lated tasks. A Measurement Controller can send a suppress message to the MA= that instructs the MA to temporarily suspend some or all of its scheduled = measurement-related tasks. Suppression ends either in response to an explic= it unsuppress message or at the time indicated in the suppress message. Sup= pression might be used when the measurement system wants to minimize inesse= ntial traffic, for example after a major network incident. Only one suppres= sion message can exist at a time in a given MA. A new suppression message c= ompletely replaces the previous one. So TR-304 would expect 1 suppression with an enable; this is quite differen= t from the behavior that changed last November. Looking for guidance. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A60F5F5US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Team,

 

I noticed that the information model has support for= multiple suppressions.

With the current definition in the information model= , it looks like there isn’t any constraints on multiple suppression r= equests that can be active at the same time.

 

I just wanted to a confirmation on this. We used to = have just 1 suppression object in an instruction. It looks like this change= d in draft-07.

 

This actually conflicts with BBF TR-304 Section 5.2 = where the text says:

Suppression is the = temporary cessation of all or a subset of measurement-related tasks. A Meas= urement Controller can send a suppress message to the MA that instructs the= MA to temporarily suspend some or all of its scheduled measurement-related tasks. Suppression ends either in res= ponse to an explicit unsuppress message or at the time indicated in the sup= press message. Suppression might be used when the measurement system wants = to minimize inessential traffic, for example after a major network incident. Only one suppression message c= an exist at a time in a given MA. A new suppression message completely repl= aces the previous one.

 

So TR-304 would exp= ect 1 suppression with an enable; this is quite different from the behavior= that changed last November.

 

 

Looking for guidanc= e.

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A60F5F5US70UWXCHMBA0_-- From nobody Thu Mar 24 08:20:42 2016 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 1E4D512DBA0 for ; Thu, 24 Mar 2016 08:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXTO1dyNbtTY for ; Thu, 24 Mar 2016 08:20:29 -0700 (PDT) Received: from s12p02o144.mxlogic.net (s12p02o144.mxlogic.net [208.65.145.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B0112DDE8 for ; Thu, 24 Mar 2016 08:05:08 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by s12p02o144.mxlogic.net(mxl_mta-8.5.0-9) with ESMTP id 42204f65.7fefc97fb700.74315.00-519.211590.s12p02o144.mxlogic.net (envelope-from ); Thu, 24 Mar 2016 09:05:08 -0600 (MDT) X-MXL-Hash: 56f40224318707ff-ed8b825a59aa7be3285cca3434a33d515973930d Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by s12p02o144.mxlogic.net(mxl_mta-8.5.0-9) over TLS secured channel with ESMTP id c0104f65.0.68816.00-118.195910.s12p02o144.mxlogic.net (envelope-from ); Thu, 24 Mar 2016 09:00:28 -0600 (MDT) X-MXL-Hash: 56f4010c1deed9c4-62ded1c7b924c50775669d3516849a18925e6986 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0266.001; Thu, 24 Mar 2016 10:00:28 -0500 From: KEN KO To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" Thread-Topic: Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUgAAFPfw Date: Thu, 24 Mar 2016 15:00:27 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.217.230] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB7CA20C925exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=MtZUnjue c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=RwIrsSeCkjgA:10 a=xqW] X-AnalysisOut: [C_Br6kY4A:10 a=7OsogOcEt9IA:10 a=9qxNCY_qAAAA:8 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=zQP7CpKOAAAA:8 a=MiICfpAliJuueXkukvUA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=fFqQZUd3SwqT9] X-AnalysisOut: [pIny1gA:9 a=sLWJyb3RNL6GmxWJ:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L] X-AnalysisOut: [4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5100000000; CM=0.500; MH=0.510(2016032408); S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: Cc: "bs7652@att.com" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:20:31 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB7CA20C925exmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tim, thanks for catching this. I'd also like to understand why lmap has cha= nged it. Ken From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] Sent: Thursday, March 24, 2016 9:57 AM To: lmap@ietf.org Cc: KEN KO; bs7652@att.com Subject: Question on multiple outstanding suppressions Team, I noticed that the information model has support for multiple suppressions. With the current definition in the information model, it looks like there i= sn't any constraints on multiple suppression requests that can be active at= the same time. I just wanted to a confirmation on this. We used to have just 1 suppression= object in an instruction. It looks like this changed in draft-07. This actually conflicts with BBF TR-304 Section 5.2 where the text says: Suppression is the temporary cessation of all or a subset of measurement-re= lated tasks. A Measurement Controller can send a suppress message to the MA= that instructs the MA to temporarily suspend some or all of its scheduled = measurement-related tasks. Suppression ends either in response to an explic= it unsuppress message or at the time indicated in the suppress message. Sup= pression might be used when the measurement system wants to minimize inesse= ntial traffic, for example after a major network incident. Only one suppres= sion message can exist at a time in a given MA. A new suppression message c= ompletely replaces the previous one. So TR-304 would expect 1 suppression with an enable; this is quite differen= t from the behavior that changed last November. Looking for guidance. BR, Tim --_000_D14B7E40AEBFD54EA3AD964902DD7CB7CA20C925exmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim, thanks for catchi= ng this. I’d also like to understand why lmap has changed it.

Ken<= /p>

 

From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.= com]
Sent: Thursday, March 24, 2016 9:57 AM
To: lmap@ietf.org
Cc: KEN KO; bs7652@att.com
Subject: Question on multiple outstanding suppressions

 

Team,

 

I noticed that the inform= ation model has support for multiple suppressions.

With the current definiti= on in the information model, it looks like there isn’t any constraint= s on multiple suppression requests that can be active at the same time.

 

I just wanted to a confir= mation on this. We used to have just 1 suppression object in an instruction= . It looks like this changed in draft-07.

 

This actually conflicts w= ith BBF TR-304 Section 5.2 where the text says:

Suppression is the temporary cessation of all or a subset of measur= ement-related tasks. A Measurement Controller can send a suppress message t= o the MA that instructs the MA to temporarily suspend some or all of its scheduled measurement-related tasks. Suppressio= n ends either in response to an explicit unsuppress message or at the time = indicated in the suppress message. Suppression might be used when the measu= rement system wants to minimize inessential traffic, for example after a major network incident. Only one = suppression message can exist at a time in a given MA. A new suppression me= ssage completely replaces the previous one.

 

So TR-304 would expect 1 suppression with an enable; this is quite = different from the behavior that changed last November.

 

 

Looking for guidance.

 

BR,

Tim

--_000_D14B7E40AEBFD54EA3AD964902DD7CB7CA20C925exmb1corpadtran_-- From nobody Thu Mar 24 08:41:29 2016 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 D389F12DD16 for ; Thu, 24 Mar 2016 08:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrPFKFmxyDUP for ; Thu, 24 Mar 2016 08:41:26 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25AC12DD2D for ; Thu, 24 Mar 2016 08:27:18 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 1B804FDF0C3E for ; Thu, 24 Mar 2016 15:27:16 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u2OFRHMh031492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Mar 2016 15:27:17 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u2OFQCaf008286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Mar 2016 15:27:17 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 24 Mar 2016 11:27:15 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Supression - stoprunning parameter question Thread-Index: AdGF4aPNkOFz5r92RQy1IYK/fa+iCA== Date: Thu, 24 Mar 2016 15:27:14 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A60F7CB@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A60F7CBUS70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Supression - stoprunning parameter question X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:41:28 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A60F7CBUS70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the information model has the following definition ma-suppression-stop-running: An optional boolean indicating whether suppression will stop any running schedules or actions. The default value for this boolean is false. My question is does the stop running attribute apply only to running schedu= les or actions that are matched? I would assume so. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A60F7CBUS70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the information model has the following definitio= n

ma-suppression-stop-running: An optional boo= lean indicating whether

suppression will stop any running=

schedules or actions. The default=

value for this boolean is false.

 

 

My question is does the stop running attribute apply= only to running schedules or actions that are matched? I would assume so.<= o:p>

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A60F7CBUS70UWXCHMBA0_-- From nobody Thu Mar 24 10:25:18 2016 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 778F012D6A5 for ; Thu, 24 Mar 2016 10:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_GwPGXJJxDK for ; Thu, 24 Mar 2016 10:25:15 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76DD12D69A for ; Thu, 24 Mar 2016 10:25:14 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id C3288CAFB626B for ; Thu, 24 Mar 2016 17:25:10 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u2OHPDaw008883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Mar 2016 17:25:13 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u2OHPCjm026432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Mar 2016 17:25:13 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 24 Mar 2016 13:25:09 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Parameter ma-status-schedule-last-invocation Thread-Index: AdGF8hv+v6whPQfKTQa1ZieBnwZkYw== Date: Thu, 24 Mar 2016 17:25:07 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A60FB58@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A60FB58US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Parameter ma-status-schedule-last-invocation X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 17:25:17 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A60FB58US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, In the latest Information model draft this parameter is defined twice. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A60FB58US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

In the latest Information model draft this parameter= is defined twice.

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A60FB58US70UWXCHMBA0_-- From nobody Thu Mar 24 10:54:29 2016 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 937F012D693 for ; Thu, 24 Mar 2016 10:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtBlmxvbs4Nm for ; Thu, 24 Mar 2016 10:54:26 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D589812D663 for ; Thu, 24 Mar 2016 10:54:26 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id D3FA31C3C2DF8 for ; Thu, 24 Mar 2016 17:54:22 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u2OHsPAj002958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Mar 2016 17:54:26 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u2OHsPHX008032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Mar 2016 17:54:25 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 24 Mar 2016 13:54:25 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Counter names for Actions Thread-Index: AdGF9jM1I+N4GTr1TDOE/k64b5UXzA== Date: Thu, 24 Mar 2016 17:54:24 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A60FC97@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A60FC97US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Counter names for Actions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 17:54:28 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A60FC97US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, I noticed the names of the counters for Actions were the same name as Sched= ule in the descriptions e.g., ma-status-schedule-invocations instead of ma-= status-action-invocations. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A60FC97US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

I noticed the names of the counters for Actions were= the same name as Schedule in the descriptions e.g., ma-status-schedule-inv= ocations instead of ma-status-action-invocations.

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A60FC97US70UWXCHMBA0_-- From nobody Thu Mar 24 11:38:12 2016 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 BA6E912D51E for ; Thu, 24 Mar 2016 11:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5YtHD6AvIMS for ; Thu, 24 Mar 2016 11:38:10 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108BD12D1AC for ; Thu, 24 Mar 2016 11:38:10 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 8494A58ED80B8 for ; Thu, 24 Mar 2016 18:38:06 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u2OIc8Zj021978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Mar 2016 18:38:09 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u2OIc8ZF028929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Mar 2016 18:38:08 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 24 Mar 2016 14:38:08 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Information Model Report Results: Question on options Thread-Index: AdGF/E700EjGvkjaQsaHSWOjnaQnPQ== Date: Thu, 24 Mar 2016 18:38:07 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A60FD6A@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A60FD6AUS70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Information Model Report Results: Question on options X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 18:38:11 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A60FD6AUS70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, In the latest IM draft (-09) you have new parameters for reporting options = and tags. ma-report-result-options: An optional ordered joined list of options provided by the task object and the action object. ma-report-result-tags: An optional unordered set of tags. This is the joined set of tags defined for the task object and the action object. What is the difference between these parameters; one says provided by the o= ther said defined for; are these tags use pre-execution and post-execution? How would an implementer know which is which? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A60FD6AUS70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

In the latest IM draft (-09) you have new parameters= for reporting options and tags.

ma-report-result-options: An optional ordere= d joined list of

options provided by the task object

and the action object.

ma-report-result-tags: An optional unordered= set of tags.

This is the joined set of tags

defined for the task object and the

action object.

 

What is the difference between these parameters; one= says provided by the other said defined for; are these tags use pre-execut= ion and post-execution?

How would an implementer know which is which?

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A60FD6AUS70UWXCHMBA0_-- From nobody Thu Mar 24 12:26:56 2016 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 F314312D680 for ; Thu, 24 Mar 2016 12:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxocjxvKYioF for ; Thu, 24 Mar 2016 12:26:53 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E7212D597 for ; Thu, 24 Mar 2016 12:26:52 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 428BD2350F994 for ; Thu, 24 Mar 2016 19:26:49 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u2OJQpwr001510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Mar 2016 19:26:51 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u2OJP251019929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Mar 2016 19:26:50 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 24 Mar 2016 15:26:25 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Information Model: Question on ma-report-result-obj Thread-Index: AdGGAw1tqtuZoD4VSNW+O269CdmACA== Date: Thu, 24 Mar 2016 19:26:24 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A60FE8F@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A60FE8FUS70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Information Model: Question on ma-report-result-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 19:26:55 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A60FE8FUS70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, I see you added the schedule name and action name to the result object (as = well as renamed it). So what makes a result unique within the report the combination of these 3 = elements? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A60FE8FUS70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

I see you added the schedule name and action name to= the result object (as well as renamed it).

 

So what makes a result unique within the report the = combination of these 3 elements?

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A60FE8FUS70UWXCHMBA0_-- From nobody Thu Mar 24 13:10:33 2016 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 A173612D84B for ; Thu, 24 Mar 2016 13:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdCv2zEk0j2P for ; Thu, 24 Mar 2016 13:10:29 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DFE12D827 for ; Thu, 24 Mar 2016 13:10:29 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 44F90DD36C6F7 for ; Thu, 24 Mar 2016 20:10:25 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u2OKAS2I000727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Mar 2016 20:10:28 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u2OKASBA010522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Mar 2016 20:10:28 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 24 Mar 2016 16:10:28 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Information model question on Events in the schedule Thread-Index: AdGGCTRobPyjJ1mDTN6t04UTp0z+gA== Date: Thu, 24 Mar 2016 20:10:27 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A60FF07@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A60FF07US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Information model question on Events in the schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 20:10:31 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A60FF07US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, I was looking at the rework of the timers in the latest draft (-09). I am quite lost on this concept with respect to event start and end times a= nd the schedule object. The schedule object had a timer object that said this schedule was active b= etween this start time and this end time (for example if you used a calenda= r timer) or is active upon an interval if you had a periodic timer. That ma= de sense to me. Now I have a schedule object that has a start parameter and optionally an (= end parameter or interval parameter). The start and end parameters themselv= es are timer objects (e.g., for a calendar has a start and end time). It would seem to me that all we need for a schedule is simply a timer that = indicates when a schedule is suppose to start and end; as it is modeled tod= ay. So lets please go back to using the timers as it was before; it just seems = simpler. If I am missing something maybe you can provide an example on paper where i= t doesn't work; because I think we are overloading event generation (timer = going off) with the configuration of the time I expect a schedule to be act= ive. Two different things... BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A60FF07US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

I was looking at the rework of the timers in the lat= est draft (-09).

 

I am quite lost on this concept with respect to even= t start and end times and the schedule object.

 

The schedule object had a timer object that said thi= s schedule was active between this start time and this end time (for exampl= e if you used a calendar timer) or is active upon an interval if you had a = periodic timer. That made sense to me.

 

Now I have a schedule object that has a start parame= ter and optionally an (end parameter or interval parameter). The start and = end parameters themselves are timer objects (e.g., for a calendar has a sta= rt and end time).

 

It would seem to me that all we need for a schedule = is simply a timer that indicates when a schedule is suppose to start and en= d; as it is modeled today.

 

So lets please go back to using the timers as it was= before; it just seems simpler.

 

If I am missing something maybe you can provide an e= xample on paper where it doesn’t work; because I think we are overloa= ding event generation (timer going off) with the configuration of the time = I expect a schedule to be active. Two different things…

 

BR,

Tim

 

 

--_000_9966516C6EB5FC4381E05BF80AA55F77012A60FF07US70UWXCHMBA0_-- From nobody Mon Mar 28 05:20:51 2016 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 2DA5F12D8E6 for ; Mon, 28 Mar 2016 05:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.929 X-Spam-Level: X-Spam-Status: No, score=-6.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv98gU3uI2mC for ; Mon, 28 Mar 2016 05:20:47 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C9E12D8EA for ; Mon, 28 Mar 2016 05:20:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D5AQDMj/NW/xUHmMZegmchK1OBA7g7gg8BDYFwIYVsAoEzOBQBAQEBAQEBZBwLhEMBAQMSG14BDAkVViYBBBsaiAUBDaBEhRKbNQEKAQEBGASGH4h/gyuCKwWXXgGFcIl5hEyDHIU9jwkeAQFCg2WJQgF9AQEB X-IPAS-Result: A2D5AQDMj/NW/xUHmMZegmchK1OBA7g7gg8BDYFwIYVsAoEzOBQBAQEBAQEBZBwLhEMBAQMSG14BDAkVViYBBBsaiAUBDaBEhRKbNQEKAQEBGASGH4h/gyuCKwWXXgGFcIl5hEyDHIU9jwkeAQFCg2WJQgF9AQEB X-IronPort-AV: E=Sophos;i="5.24,383,1454994000"; d="scan'208,217";a="148499249" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Mar 2016 08:20:43 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 28 Mar 2016 08:20:43 -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.0174.001; Mon, 28 Mar 2016 14:20:42 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: agenda and meeting logistics for IETF 95 Thread-Index: AdGI7D4Zc7OSHZMKT4a+jUUX+0XMeQ== Date: Mon, 28 Mar 2016 12:20:41 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA751A3F18@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.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA751A3F18AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] agenda and meeting logistics for IETF 95 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 12:20:49 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA751A3F18AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The agenda of the WG meeting at IETF 95 is available at https://datatracker= .ietf.org/meeting/95/agenda/lmap/. If there are any last minute requests fo= r new items or changes please let us know today! Remote participation is possible. Right now we have only Juergen registered= as a remote participant. If there are more requests, please let us know. T= he Meetecho team may contact the remote participants before the meeting to = check connectivity and optimize quality. As in all meetings, we need two note takers and one jabber scribe. Please v= olunteer! Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA751A3F18AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The agenda of the WG meeting at IETF 95 is available= at https://datatracker.ietf.org/meeting/95/agenda/lmap/. If there are any = last minute requests for new items or changes please let us know today!

 

Remote participation is possible. Right now we have = only Juergen registered as a remote participant. If there are more requests= , please let us know. The Meetecho team may contact the remote participants= before the meeting to check connectivity and optimize quality.

 

As in all meetings, we need two note takers and one = jabber scribe. Please volunteer!

 

Thanks and Regards,

 

Jason and Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA751A3F18AZFFEXMB04globa_-- From nobody Tue Mar 29 01:48:25 2016 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 9E4AA12D57F for ; Tue, 29 Mar 2016 01:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBTboI1g0x5a for ; Tue, 29 Mar 2016 01:48:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE2112D0F9 for ; Tue, 29 Mar 2016 01:48:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EA045E74; Tue, 29 Mar 2016 10:48:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id c9Ra0v8Y5onU; Tue, 29 Mar 2016 10:48:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Mar 2016 10:48:18 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1183520045; Tue, 29 Mar 2016 10:48:18 +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 mFKIWM7y3eSt; Tue, 29 Mar 2016 10:48: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 1936920043; Tue, 29 Mar 2016 10:48:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4F0673A61E14; Tue, 29 Mar 2016 10:48:15 +0200 (CEST) Date: Tue, 29 Mar 2016 10:48:14 +0200 From: Juergen Schoenwaelder To: KEN KO Message-ID: <20160329084814.GA38204@elstar.local> Mail-Followup-To: KEN KO , "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" , "bs7652@att.com" References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 08:48:23 -0000 The original reasoning can be found here: https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tbFI Not being able to provision multiple suppressions seems a major limitation to me. /js On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > Tim, thanks for catching this. I'd also like to understand why lmap has changed it. > Ken > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Thursday, March 24, 2016 9:57 AM > To: lmap@ietf.org > Cc: KEN KO; bs7652@att.com > Subject: Question on multiple outstanding suppressions > > Team, > > I noticed that the information model has support for multiple suppressions. > With the current definition in the information model, it looks like there isn't any constraints on multiple suppression requests that can be active at the same time. > > I just wanted to a confirmation on this. We used to have just 1 suppression object in an instruction. It looks like this changed in draft-07. > > This actually conflicts with BBF TR-304 Section 5.2 where the text says: > Suppression is the temporary cessation of all or a subset of measurement-related tasks. A Measurement Controller can send a suppress message to the MA that instructs the MA to temporarily suspend some or all of its scheduled measurement-related tasks. Suppression ends either in response to an explicit unsuppress message or at the time indicated in the suppress message. Suppression might be used when the measurement system wants to minimize inessential traffic, for example after a major network incident. Only one suppression message can exist at a time in a given MA. A new suppression message completely replaces the previous one. > > So TR-304 would expect 1 suppression with an enable; this is quite different from the behavior that changed last November. > > > Looking for guidance. > > BR, > Tim > _______________________________________________ > 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 nobody Tue Mar 29 01:55:59 2016 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 AD65412D585 for ; Tue, 29 Mar 2016 01:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NozABoTfHYmT for ; Tue, 29 Mar 2016 01:55:57 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C66B12D582 for ; Tue, 29 Mar 2016 01:55:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 22F83E4E; Tue, 29 Mar 2016 10:55:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uG70yub4jPoK; Tue, 29 Mar 2016 10:55:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Mar 2016 10:55:55 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F9E220047; Tue, 29 Mar 2016 10:55:55 +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 NGl6mtzdy0uA; Tue, 29 Mar 2016 10:55:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 696A420043; Tue, 29 Mar 2016 10:55:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9D5173A61E87; Tue, 29 Mar 2016 10:55:53 +0200 (CEST) Date: Tue, 29 Mar 2016 10:55:53 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160329085553.GB38204@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A60F7CB@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A60F7CB@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Supression - stoprunning parameter question X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 08:55:58 -0000 On Thu, Mar 24, 2016 at 03:27:14PM +0000, Carey, Timothy (Nokia - US) wrote: > In the information model has the following definition > ma-suppression-stop-running: An optional boolean indicating whether > suppression will stop any running > schedules or actions. The default > value for this boolean is false. > > > My question is does the stop running attribute apply only to running schedules or actions that are matched? I would assume so. > Yes. I will try to clarify 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 nobody Tue Mar 29 06:17:39 2016 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 0FAFA12D7D9 for ; Tue, 29 Mar 2016 06:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVHkjy9lMVZs for ; Tue, 29 Mar 2016 06:17:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD96312D17A for ; Tue, 29 Mar 2016 06:17:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 75739F6C; Tue, 29 Mar 2016 15:17:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id iS9r2otGt7Xh; Tue, 29 Mar 2016 15:17:26 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Mar 2016 15:17:33 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB02E20045; Tue, 29 Mar 2016 15:17:33 +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 zK_qxC3QMZsl; Tue, 29 Mar 2016 15:17: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 2CC4A20043; Tue, 29 Mar 2016 15:17:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 27A023A62321; Tue, 29 Mar 2016 15:17:31 +0200 (CEST) Date: Tue, 29 Mar 2016 15:17:31 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160329131731.GB39533@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A60FB58@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A60FB58@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Parameter ma-status-schedule-last-invocation X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 13:17:38 -0000 On Thu, Mar 24, 2016 at 05:25:07PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > In the latest Information model draft this parameter is defined twice. > Thanks, fixed in my sources. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 29 06:23:03 2016 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 9F28512D1A8 for ; Tue, 29 Mar 2016 06:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_kHJiaZZ--9 for ; Tue, 29 Mar 2016 06:22:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6937D12D1AB for ; Tue, 29 Mar 2016 06:22:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 30DB522A1; Tue, 29 Mar 2016 15:22:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id vh9Qd63F7MtR; Tue, 29 Mar 2016 15:22:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Mar 2016 15:22:54 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FB6220046; Tue, 29 Mar 2016 15:22:54 +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 EIn1JZ8cXeRA; Tue, 29 Mar 2016 15:22:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30C6B20045; Tue, 29 Mar 2016 15:22:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2C95A3A623C4; Tue, 29 Mar 2016 15:22:53 +0200 (CEST) Date: Tue, 29 Mar 2016 15:22:53 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160329132253.GC39533@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A60FC97@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A60FC97@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Counter names for Actions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 13:23:02 -0000 On Thu, Mar 24, 2016 at 05:54:24PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I noticed the names of the counters for Actions were the same name as Schedule in the descriptions e.g., ma-status-schedule-invocations instead of ma-status-action-invocations. > Thanks, fixed in my sources. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 29 07:38:07 2016 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 63A7512D89D for ; Tue, 29 Mar 2016 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77ZchmR7JUlF for ; Tue, 29 Mar 2016 07:38:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C2512D89C for ; Tue, 29 Mar 2016 07:38:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A081A13E4; Tue, 29 Mar 2016 16:38:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id s9UvC7FyXXQn; Tue, 29 Mar 2016 16:37:53 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Mar 2016 16:38:00 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D28D420046; Tue, 29 Mar 2016 16:38:00 +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 kPAFIPPKkW8w; Tue, 29 Mar 2016 16:38:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EF5220043; Tue, 29 Mar 2016 16:37:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B12C73A624E7; Tue, 29 Mar 2016 16:37:58 +0200 (CEST) Date: Tue, 29 Mar 2016 16:37:57 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160329143757.GA39988@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A60FD6A@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A60FD6A@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model Report Results: Question on options X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 14:38:05 -0000 On Thu, Mar 24, 2016 at 06:38:07PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > In the latest IM draft (-09) you have new parameters for reporting options and tags. > ma-report-result-options: An optional ordered joined list of > options provided by the task object > and the action object. > ma-report-result-tags: An optional unordered set of tags. > This is the joined set of tags > defined for the task object and the > action object. > > What is the difference between these parameters; one says provided by the other said defined for; are these tags use pre-execution and post-execution? > How would an implementer know which is which? > I am not sure I got your question. Let me try to explain. - You can configure a list of options on the ma-task-obj and you can set additional list of options on the ma-action-obj. The list of options used is the concatenation of both lists. In the result report, the ma-report-result-options field reports this joined list of options that were in force when the action was started. - You can configure a set of tags in the ma-task-obj and you can set an additional set of tags on the ma-action-obj. The result report carries the joined set of tags that were set when the action was started. I guess I should use 'provided by' in both cases. I have changes this in the sources. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 29 07:44:36 2016 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 D286212D8AD for ; Tue, 29 Mar 2016 07:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSAQivwaQXxd for ; Tue, 29 Mar 2016 07:44:33 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697DC12D895 for ; Tue, 29 Mar 2016 07:44:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2D52D2256; Tue, 29 Mar 2016 16:44:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uVwL4wBlQcIe; Tue, 29 Mar 2016 16:44:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Mar 2016 16:44:31 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57EF120045; Tue, 29 Mar 2016 16:44:31 +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 Z9KgUAkF3bXu; Tue, 29 Mar 2016 16:44: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 67F0720043; Tue, 29 Mar 2016 16:44:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 65A783A62523; Tue, 29 Mar 2016 16:44:30 +0200 (CEST) Date: Tue, 29 Mar 2016 16:44:30 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160329144430.GB39988@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A60FE8F@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A60FE8F@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Question on ma-report-result-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 14:44:35 -0000 On Thu, Mar 24, 2016 at 07:26:24PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I see you added the schedule name and action name to the result object (as well as renamed it). > > So what makes a result unique within the report the combination of these 3 elements? > The unique key would be the schedule name and the action name (because this identifies an action) combined with the start-time. The task name is not strictly necessary and more a matter of convenience. One possible issue is the conflict list, which is simply a list of task names. So the collector does not get to know which actions in which schedules actually caused a conflict. The alternative would be to make this a list of (schedule name, action name) pairs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 29 07:47:58 2016 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 10D3012D89D for ; Tue, 29 Mar 2016 07:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE7z2O5DS4kR for ; Tue, 29 Mar 2016 07:47:55 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C944F12D8B2 for ; Tue, 29 Mar 2016 07:47:41 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id F237C36049ECD; Tue, 29 Mar 2016 14:40:39 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u2TEefRJ021448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2016 14:40:42 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u2TEeeN8027092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Mar 2016 14:40:41 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 29 Mar 2016 10:40:41 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model Report Results: Question on options Thread-Index: AQHRiciiKfPKR1THFEONx7/fpaW0Yp9wfdyw Date: Tue, 29 Mar 2016 14:40:40 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A614084@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A60FD6A@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329143757.GA39988@elstar.local> In-Reply-To: <20160329143757.GA39988@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 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model Report Results: Question on options X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 14:47:57 -0000 Juergen, Thanks for the explanation I understand the difference now. BR, Tim=20 -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Tuesday, March 29, 2016 9:38 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model Report Results: Question on options On Thu, Mar 24, 2016 at 06:38:07PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > In the latest IM draft (-09) you have new parameters for reporting option= s and tags. > ma-report-result-options: An optional ordered joined list of options=20 > provided by the task object and the action object. > ma-report-result-tags: An optional unordered set of tags. > This is the joined set of tags > defined for the task object and the > action object. >=20 > What is the difference between these parameters; one says provided by the= other said defined for; are these tags use pre-execution and post-executio= n? > How would an implementer know which is which? > I am not sure I got your question. Let me try to explain. - You can configure a list of options on the ma-task-obj and you can set additional list of options on the ma-action-obj. The list of options used is the concatenation of both lists. In the result report, the ma-report-result-options field reports this joined list of options that were in force when the action was started. - You can configure a set of tags in the ma-task-obj and you can set an additional set of tags on the ma-action-obj. The result report carries the joined set of tags that were set when the action was started. =20 I guess I should use 'provided by' in both cases. I have changes this in th= e sources. /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 nobody Tue Mar 29 08:26:04 2016 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 5610312D987 for ; Tue, 29 Mar 2016 08:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgI95SwNc4wq for ; Tue, 29 Mar 2016 08:25:57 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E48A12D952 for ; Tue, 29 Mar 2016 08:25:06 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 396D52F531B1D; Tue, 29 Mar 2016 15:13:30 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u2TFDWub021825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2016 15:13:32 GMT 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 u2TFDVfO010795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Mar 2016 15:13:31 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 29 Mar 2016 11:13:31 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model: Question on ma-report-result-obj Thread-Index: AQHRicmLdo2d7njSjEWG0GZeuFrsTZ9whtlg Date: Tue, 29 Mar 2016 15:13:30 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A614158@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A60FE8F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329144430.GB39988@elstar.local> In-Reply-To: <20160329144430.GB39988@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 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Question on ma-report-result-obj X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 15:26:02 -0000 Thanks Juergen, I'll use that as a key - we should document that in the information model t= o remove any confusion. Yes I agree the conflict list in the report ought be the action instance th= at caused the conflict. Good catch! BR, Tim -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Tuesday, March 29, 2016 9:45 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model: Question on ma-report-result-obj On Thu, Mar 24, 2016 at 07:26:24PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > I see you added the schedule name and action name to the result object (a= s well as renamed it). >=20 > So what makes a result unique within the report the combination of these = 3 elements? >=20 The unique key would be the schedule name and the action name (because this= identifies an action) combined with the start-time. The task name is not s= trictly necessary and more a matter of convenience. One possible issue is the conflict list, which is simply a list of task nam= es. So the collector does not get to know which actions in which schedules = actually caused a conflict. The alternative would be to make this a list of= (schedule name, action name) pairs. /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 nobody Tue Mar 29 10:10:10 2016 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 3688A12DB48 for ; Tue, 29 Mar 2016 10:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OvUBKPp9ZBK for ; Tue, 29 Mar 2016 10:10:02 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E820B12DC69 for ; Tue, 29 Mar 2016 09:58:30 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 173FDFB82774E; Tue, 29 Mar 2016 16:58:27 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u2TGwSqr030137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2016 16:58:29 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u2TGwSsT020445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Mar 2016 16:58:28 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 29 Mar 2016 12:58:28 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , KEN KO Thread-Topic: [lmap] Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUgAAFPfwAPbj/QAACBWu0A== Date: Tue, 29 Mar 2016 16:58:26 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> In-Reply-To: <20160329084814.GA38204@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 Archived-At: Cc: "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 17:10:09 -0000 Juergen, I suspect it was with good reason that the BBF wanted this as a single inst= ance active at a time.=20 Possibly Ken or Barbara could provide the reasoning. Minimally I would think we would need to be able administratively enable/di= sable a suppression object; that at least lets me shut them down temporaril= y. BR, Tim -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Tuesday, March 29, 2016 3:48 AM To: KEN KO Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com Subject: Re: [lmap] Question on multiple outstanding suppressions The original reasoning can be found here: https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tbFI Not being able to provision multiple suppressions seems a major limitation = to me. /js On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > Tim, thanks for catching this. I'd also like to understand why lmap has c= hanged it. > Ken >=20 > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Thursday, March 24, 2016 9:57 AM > To: lmap@ietf.org > Cc: KEN KO; bs7652@att.com > Subject: Question on multiple outstanding suppressions >=20 > Team, >=20 > I noticed that the information model has support for multiple suppression= s. > With the current definition in the information model, it looks like there= isn't any constraints on multiple suppression requests that can be active = at the same time. >=20 > I just wanted to a confirmation on this. We used to have just 1 suppressi= on object in an instruction. It looks like this changed in draft-07. >=20 > This actually conflicts with BBF TR-304 Section 5.2 where the text says: > Suppression is the temporary cessation of all or a subset of measurement-= related tasks. A Measurement Controller can send a suppress message to the = MA that instructs the MA to temporarily suspend some or all of its schedule= d measurement-related tasks. Suppression ends either in response to an expl= icit unsuppress message or at the time indicated in the suppress message. S= uppression might be used when the measurement system wants to minimize ines= sential traffic, for example after a major network incident. Only one suppr= ession message can exist at a time in a given MA. A new suppression message= completely replaces the previous one. >=20 > So TR-304 would expect 1 suppression with an enable; this is quite differ= ent from the behavior that changed last November. >=20 >=20 > Looking for guidance. >=20 > BR, > Tim > _______________________________________________ > 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 nobody Tue Mar 29 10:32:21 2016 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 5F1F012DEB2 for ; Tue, 29 Mar 2016 10:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTB9ocLZTrrL for ; Tue, 29 Mar 2016 10:32:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA27512D99E for ; Tue, 29 Mar 2016 10:18:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 80FBF751; Tue, 29 Mar 2016 19:18:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id J7Awevn6TG10; Tue, 29 Mar 2016 19:18:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Mar 2016 19:18:13 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57BDF20045; Tue, 29 Mar 2016 19:18:13 +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 iqx0JhF7C87U; Tue, 29 Mar 2016 19:18:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C54D20043; Tue, 29 Mar 2016 19:18:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 54CDF3A62786; Tue, 29 Mar 2016 19:18:10 +0200 (CEST) Date: Tue, 29 Mar 2016 19:18:09 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160329171809.GC40459@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A60FF07@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A60FF07@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information model question on Events in the schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 17:32:20 -0000 On Thu, Mar 24, 2016 at 08:10:27PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I was looking at the rework of the timers in the latest draft (-09). > > I am quite lost on this concept with respect to event start and end times and the schedule object. > > The schedule object had a timer object that said this schedule was active between this start time and this end time (for example if you used a calendar timer) or is active upon an interval if you had a periodic timer. That made sense to me. This is not correct. > Now I have a schedule object that has a start parameter and optionally an (end parameter or interval parameter). The start and end parameters themselves are timer objects (e.g., for a calendar has a start and end time). Yep, this can be configured. > It would seem to me that all we need for a schedule is simply a timer that indicates when a schedule is suppose to start and end; as it is modeled today. > > So lets please go back to using the timers as it was before; it just seems simpler. No. The timers serve different purposes. There was no schedule end in earlier versions, Al Morton came up with the requirement to be able to control the duration of an active schedule. > If I am missing something maybe you can provide an example on paper where it doesn't work; because I think we are overloading event generation (timer going off) with the configuration of the time I expect a schedule to be active. Two different things... No, I believe this is clearly separated. Lets first talk about events and lets pick calendar events as an example (since you mentioned them). A calendar event specification can express that an event should be created lets say every day at 03:42:00. The optional ma-calendar-start and ma-calendar-end descripts say this: ma-calendar-start: The optional date and time at which Schedules using this object are first started. If not present it defaults to immediate. ma-calendar-end: The optional date and time at which Schedules using this object are last started. If not present it defaults to indefinite. If you do not set these fields, you fire an event every day at 03:42:00. By setting ma-calendar-start to 2016-04-01T00:00:00, the first time this calendar entry will fire an event is at 2016-04-01T03:42:00 but nothing will happen before April 1st. If you set ma-calendar-end to 2016-05-01T00:00:00, the the last time this calendar entry will fire an event is at 2016-04-30T03:42:00. In other words, the ma-calendar-start and ma-calendar-end define the time interval in which the periodic event source is 'active'. Now lets talk about scheduled. A schedule is started when the start ma-schedule-start event takes place (and the schedule is not currently active). ma-schedule-start: An event object indicating when the schedule starts. ma-schedule-end: An optional event object controlling the forceful termination of scheduled actions. When the event occurs, all actions of the schedule will be forced to terminate gracefully. ma-schedule-duration: An optional duration in seconds for the schedule. All actions of the schedule will be forced to terminate gracefully after the duration number of seconds past the start of the schedule. If you do not specify ma-schedule-end or ma-schedule-duration, the action will run until all actions have finished. If you set ma-schedule-duration, then you define a maximum running time for the schedule. If you set ma-schedule-end, then you define an event that causes the schedule to terminate when the event fires. Do you see that all these objects do have a specific purpose and do not overlap? Timer events are a specific point in time, schedules are started by an event and they either run until completion or they are optionally terminated after a certain duration or when an end event fires. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 29 10:40:44 2016 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 214A212DF7B for ; Tue, 29 Mar 2016 10:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRwEB_Ija0xj for ; Tue, 29 Mar 2016 10:40:39 -0700 (PDT) Received: from s12p02o148.mxlogic.net (s12p02o148.mxlogic.net [208.65.145.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C253012DDE3 for ; Tue, 29 Mar 2016 10:23:02 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO s12p02o148.mxlogic.net) by s12p02o148.mxlogic.net(mxl_mta-8.5.0-9) with ESMTP id 6f9baf65.7f57461fc700.92457.00-593.261089.s12p02o148.mxlogic.net (envelope-from ); Tue, 29 Mar 2016 11:23:02 -0600 (MDT) X-MXL-Hash: 56fab9f6515e5f76-d4c17dd6aaaae8b18bd193776154def743bf3c70 Received: from unknown [76.164.174.83] by s12p02o148.mxlogic.net(mxl_mta-8.5.0-9) over TLS secured channel with SMTP id 0f9baf65.0.92337.00-343.260757.s12p02o148.mxlogic.net (envelope-from ); Tue, 29 Mar 2016 11:22:59 -0600 (MDT) X-MXL-Hash: 56fab9f348149781-7a096be6c851d1410ee0e2069c1134d57433479f Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0266.001; Tue, 29 Mar 2016 12:22:55 -0500 From: KEN KO To: "Carey, Timothy (Nokia - US)" , "Juergen Schoenwaelder" Thread-Topic: [lmap] Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUgAAFPfwAPj8bgAAER67AAAKO3Ag Date: Tue, 29 Mar 2016 17:22:55 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.180.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=cYPU2y3M c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=npYA5sRtbnUA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=7OsogOcEt9IA:10 a=9qxNCY_] X-AnalysisOut: [qAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=j3Z76cjpAAAA:8] X-AnalysisOut: [ a=fpLYGuIOplaVqEfqtk0A:9 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA] X-AnalysisOut: [:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2016032914); S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: Cc: "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 17:40:42 -0000 TR-304 (from BBF) and RFC 7594 both document suppression as a single instan= ce. It is intended to be used as a fairly blunt instrument, for instance to= prevent measurement traffic from exacerbating network congestion during an= unusual event. >From TR-304 section 5.2: "Suppression might be used when the measurement sy= stem wants to minimize inessential traffic, for example after a major netwo= rk incident. Only one suppression message can exist at a time in a given MA= . A new suppression message completely replaces the previous one." >From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is to e= nable the Measurement System to eliminate Measurement Traffic, because ther= e is some unexpected network issue, for example. There may be other circum= stances when Suppression is useful, for example, to eliminate inessential R= eporting traffic (even if there is no Measurement Traffic). >From RFC 7594 section 5.2.2: "However, Suppression information always repla= ces (rather than adds to) any previous Suppression information." The idea in both documents was to provide a mechanism that was flexible in = how tasks could be configured to react to it, but simple in how the "panic = button" would be pushed in the case of a network event.=20 >From the archive link Juergen provided, it looks like the purpose of suppre= ssion in the information model has changed fairly dramatically, and that it= is now a more generic capability to disable tasks according to any of mult= iple schedules. I'm concerned that it may no longer provide the simple "pan= ic button" that was intended. Do we really want to deviate in this way from= something that was defined specifically in the framework documents, which = after all are intended to provide guidance for more detailed documentation? Ken -----Original Message----- From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com]=20 Sent: Tuesday, March 29, 2016 12:58 PM To: Juergen Schoenwaelder; KEN KO Cc: lmap@ietf.org; bs7652@att.com Subject: RE: [lmap] Question on multiple outstanding suppressions Juergen, I suspect it was with good reason that the BBF wanted this as a single inst= ance active at a time.=20 Possibly Ken or Barbara could provide the reasoning. Minimally I would think we would need to be able administratively enable/di= sable a suppression object; that at least lets me shut them down temporaril= y. BR, Tim -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Tuesday, March 29, 2016 3:48 AM To: KEN KO Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com Subject: Re: [lmap] Question on multiple outstanding suppressions The original reasoning can be found here: https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tbFI Not being able to provision multiple suppressions seems a major limitation = to me. /js On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > Tim, thanks for catching this. I'd also like to understand why lmap has c= hanged it. > Ken >=20 > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Thursday, March 24, 2016 9:57 AM > To: lmap@ietf.org > Cc: KEN KO; bs7652@att.com > Subject: Question on multiple outstanding suppressions >=20 > Team, >=20 > I noticed that the information model has support for multiple suppression= s. > With the current definition in the information model, it looks like there= isn't any constraints on multiple suppression requests that can be active = at the same time. >=20 > I just wanted to a confirmation on this. We used to have just 1 suppressi= on object in an instruction. It looks like this changed in draft-07. >=20 > This actually conflicts with BBF TR-304 Section 5.2 where the text says: > Suppression is the temporary cessation of all or a subset of measurement-= related tasks. A Measurement Controller can send a suppress message to the = MA that instructs the MA to temporarily suspend some or all of its schedule= d measurement-related tasks. Suppression ends either in response to an expl= icit unsuppress message or at the time indicated in the suppress message. S= uppression might be used when the measurement system wants to minimize ines= sential traffic, for example after a major network incident. Only one suppr= ession message can exist at a time in a given MA. A new suppression message= completely replaces the previous one. >=20 > So TR-304 would expect 1 suppression with an enable; this is quite differ= ent from the behavior that changed last November. >=20 >=20 > Looking for guidance. >=20 > BR, > Tim > _______________________________________________ > 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 nobody Tue Mar 29 10:41:48 2016 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 AB4E112DB08 for ; Tue, 29 Mar 2016 10:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Apiv3udZigI for ; Tue, 29 Mar 2016 10:41:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DFD812DB1E for ; Tue, 29 Mar 2016 10:23:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 51873132F; Tue, 29 Mar 2016 19:23:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xpgszYOL8NO5; Tue, 29 Mar 2016 19:23:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Mar 2016 19:23:42 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FF0620045; Tue, 29 Mar 2016 19:23:42 +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 eEaQbewwHZjl; Tue, 29 Mar 2016 19:23:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1505E20043; Tue, 29 Mar 2016 19:23:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 10E7C3A62801; Tue, 29 Mar 2016 19:23:41 +0200 (CEST) Date: Tue, 29 Mar 2016 19:23:41 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160329172340.GA40617@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , KEN KO , "lmap@ietf.org" , "bs7652@att.com" References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "bs7652@att.com" , KEN KO , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 17:41:47 -0000 On Tue, Mar 29, 2016 at 04:58:26PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I suspect it was with good reason that the BBF wanted this as a single instance active at a time. > > Possibly Ken or Barbara could provide the reasoning. > > Minimally I would think we would need to be able administratively enable/disable a suppression object; that at least lets me shut them down temporarily. > Simply set the match to something that does not match anything or delete and recreate the suppression or ... If we start to add enable/disable knobs here, we will end having them everywhere. In the NETCONF world, there once was a proposal to have a generic enable/disable mechanism but it did run out of steam. But I would prefer to have a general mechanism for this instead of enable/disable knobs everywhere. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 29 11:18:29 2016 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 01CB012E256 for ; Tue, 29 Mar 2016 11:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBnGKcA7_l0o for ; Tue, 29 Mar 2016 11:18:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E0812DEB2 for ; Tue, 29 Mar 2016 10:33:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 285A21108; Tue, 29 Mar 2016 19:33:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4cKA9VDnX9VM; Tue, 29 Mar 2016 19:32:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Mar 2016 19:33:00 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C79A20045; Tue, 29 Mar 2016 19:33:00 +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 rfWdu3UmwVQA; Tue, 29 Mar 2016 19:32:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4B7820043; Tue, 29 Mar 2016 19:32:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A1FC13A62848; Tue, 29 Mar 2016 19:32:57 +0200 (CEST) Date: Tue, 29 Mar 2016 19:32:57 +0200 From: Juergen Schoenwaelder To: KEN KO Message-ID: <20160329173257.GB40617@elstar.local> Mail-Followup-To: KEN KO , "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" , "bs7652@att.com" References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 18:18:28 -0000 You can still use suppressions as a panic button. You can have multiple panic buttons if you want to (but you do not have to use it in that way). You can have automatic pre-configured panic buttons (the new years evening example) but you do not have to use it that way. If you read the emails, you will note that we had not only panic buttons but also a second mechanism to handle the loss of the controller. Instead of having multiple hardwired mechanisms to disable 'things', the proposal back then was to generalize _one_ mechanism so that it can do it all. The suppressions we have now makes code simpler, extensible and more powerful at the same time. I do not see a good reason to go back. /js On Tue, Mar 29, 2016 at 05:22:55PM +0000, KEN KO wrote: > TR-304 (from BBF) and RFC 7594 both document suppression as a single instance. It is intended to be used as a fairly blunt instrument, for instance to prevent measurement traffic from exacerbating network congestion during an unusual event. > > From TR-304 section 5.2: "Suppression might be used when the measurement system wants to minimize inessential traffic, for example after a major network incident. Only one suppression message can exist at a time in a given MA. A new suppression message completely replaces the previous one." > > From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is to enable the Measurement System to eliminate Measurement Traffic, because there is some unexpected network issue, for example. There may be other circumstances when Suppression is useful, for example, to eliminate inessential Reporting traffic (even if there is no Measurement Traffic). > > From RFC 7594 section 5.2.2: "However, Suppression information always replaces (rather than adds to) any previous Suppression information." > > The idea in both documents was to provide a mechanism that was flexible in how tasks could be configured to react to it, but simple in how the "panic button" would be pushed in the case of a network event. > > From the archive link Juergen provided, it looks like the purpose of suppression in the information model has changed fairly dramatically, and that it is now a more generic capability to disable tasks according to any of multiple schedules. I'm concerned that it may no longer provide the simple "panic button" that was intended. Do we really want to deviate in this way from something that was defined specifically in the framework documents, which after all are intended to provide guidance for more detailed documentation? > > Ken > > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Tuesday, March 29, 2016 12:58 PM > To: Juergen Schoenwaelder; KEN KO > Cc: lmap@ietf.org; bs7652@att.com > Subject: RE: [lmap] Question on multiple outstanding suppressions > > Juergen, > > I suspect it was with good reason that the BBF wanted this as a single instance active at a time. > > Possibly Ken or Barbara could provide the reasoning. > > Minimally I would think we would need to be able administratively enable/disable a suppression object; that at least lets me shut them down temporarily. > > BR, > Tim > > -----Original Message----- > From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, March 29, 2016 3:48 AM > To: KEN KO > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > Subject: Re: [lmap] Question on multiple outstanding suppressions > > The original reasoning can be found here: > > https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tbFI > > Not being able to provision multiple suppressions seems a major limitation to me. > > /js > > On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > > Tim, thanks for catching this. I'd also like to understand why lmap has changed it. > > Ken > > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Thursday, March 24, 2016 9:57 AM > > To: lmap@ietf.org > > Cc: KEN KO; bs7652@att.com > > Subject: Question on multiple outstanding suppressions > > > > Team, > > > > I noticed that the information model has support for multiple suppressions. > > With the current definition in the information model, it looks like there isn't any constraints on multiple suppression requests that can be active at the same time. > > > > I just wanted to a confirmation on this. We used to have just 1 suppression object in an instruction. It looks like this changed in draft-07. > > > > This actually conflicts with BBF TR-304 Section 5.2 where the text says: > > Suppression is the temporary cessation of all or a subset of measurement-related tasks. A Measurement Controller can send a suppress message to the MA that instructs the MA to temporarily suspend some or all of its scheduled measurement-related tasks. Suppression ends either in response to an explicit unsuppress message or at the time indicated in the suppress message. Suppression might be used when the measurement system wants to minimize inessential traffic, for example after a major network incident. Only one suppression message can exist at a time in a given MA. A new suppression message completely replaces the previous one. > > > > So TR-304 would expect 1 suppression with an enable; this is quite different from the behavior that changed last November. > > > > > > Looking for guidance. > > > > BR, > > Tim > > > _______________________________________________ > > 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 nobody Tue Mar 29 11:52:28 2016 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 1C05D12DB07 for ; Tue, 29 Mar 2016 11:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcYJTFjzpvxd for ; Tue, 29 Mar 2016 11:52:24 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7F912DCBA for ; Tue, 29 Mar 2016 11:18:10 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 128DC3035AF6A; Tue, 29 Mar 2016 17:47:20 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u2THlNeR017266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2016 17:47:23 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u2THlN6E032331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Mar 2016 17:47:23 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 29 Mar 2016 13:47:23 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information model question on Events in the schedule Thread-Index: AQHRid8Co6YkaVHid0u0DyBcFtvo5p9wsZEA Date: Tue, 29 Mar 2016 17:47:22 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A614595@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A60FF07@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329171809.GC40459@elstar.local> In-Reply-To: <20160329171809.GC40459@elstar.local> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information model question on Events in the schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 18:52:27 -0000 Juergen, I guess I will have to break this down abit by question in order for me to = understand. Inline for the first clarification. -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Tuesday, March 29, 2016 12:18 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information model question on Events in the schedule On Thu, Mar 24, 2016 at 08:10:27PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > I was looking at the rework of the timers in the latest draft (-09). >=20 > I am quite lost on this concept with respect to event start and end times= and the schedule object. >=20 > The schedule object had a timer object that said this schedule was active= between this start time and this end time (for example if you used a calen= dar timer) or is active upon an interval if you had a periodic timer. That = made sense to me. This is not correct. Why do you say this is not correct. I have a schedule object that is = associated with a calendar timer (as an example). That would mean in this i= nstance the schedule would start and stop at that time - Period. What am I = missing? =20 > Now I have a schedule object that has a start parameter and optionally an= (end parameter or interval parameter). The start and end parameters themse= lves are timer objects (e.g., for a calendar has a start and end time). Yep, this can be configured. > It would seem to me that all we need for a schedule is simply a timer tha= t indicates when a schedule is suppose to start and end; as it is modeled t= oday. >=20 > So lets please go back to using the timers as it was before; it just seem= s simpler. No. The timers serve different purposes. There was no schedule end in earli= er versions, Al Morton came up with the requirement to be able to control t= he duration of an active schedule. > If I am missing something maybe you can provide an example on paper where= it doesn't work; because I think we are overloading event generation (time= r going off) with the configuration of the time I expect a schedule to be a= ctive. Two different things... No, I believe this is clearly separated. Lets first talk about events and l= ets pick calendar events as an example (since you mentioned them). A calend= ar event specification can express that an event should be created lets say= every day at 03:42:00. The optional ma-calendar-start and ma-calendar-end = descripts say this: ma-calendar-start: The optional date and time at which Schedules using this object are first started. If not present it defaults to immediate. ma-calendar-end: The optional date and time at which Schedules using this object are last started. If not present it defaults to indefinite. If you do not set these fields, you fire an event every day at 03:42:00. By= setting ma-calendar-start to 2016-04-01T00:00:00, the first time this cale= ndar entry will fire an event is at 2016-04-01T03:42:00 but nothing will happen before April 1st. If you set ma= -calendar-end to 2016-05-01T00:00:00, the the last time this calendar entry= will fire an event is at 2016-04-30T03:42:00. In other words, the ma-calen= dar-start and ma-calendar-end define the time interval in which the periodi= c event source is 'active'. Now lets talk about scheduled. A schedule is started when the start ma-sche= dule-start event takes place (and the schedule is not currently active).=20 ma-schedule-start: An event object indicating when the schedule starts. ma-schedule-end: An optional event object controlling the forceful termination of scheduled actions. When the event occurs, all actions of the schedule will be forced to terminate gracefully. ma-schedule-duration: An optional duration in seconds for the schedule. All actions of the schedule will be forced to terminate gracefully after the duration number of seconds past the start of the schedule. If you do not specify ma-schedule-end or ma-schedule-duration, the action w= ill run until all actions have finished. If you set ma-schedule-duration, t= hen you define a maximum running time for the schedule. If you set ma-sched= ule-end, then you define an event that causes the schedule to terminate whe= n the event fires. Do you see that all these objects do have a specific purpose and do not ove= rlap? Timer events are a specific point in time, schedules are started by a= n event and they either run until completion or they are optionally termina= ted after a certain duration or when an end event fires. /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 nobody Tue Mar 29 14:00:51 2016 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 6BA7712D50C for ; Tue, 29 Mar 2016 14:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHGcfG4Csax6 for ; Tue, 29 Mar 2016 14:00:45 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBD812DE43 for ; Tue, 29 Mar 2016 13:31:08 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 14A3653F5AC0F; Tue, 29 Mar 2016 20:31:04 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u2TKV7K1027926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2016 20:31:07 GMT 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 u2TKV6V9017815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Mar 2016 20:31:06 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 29 Mar 2016 16:31:06 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , KEN KO Thread-Topic: [lmap] Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUgAAFPfwAPbj/QAACBWu0AAJ4/OAAABZtYAAAkhGkA== Date: Tue, 29 Mar 2016 20:31:06 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329173257.GB40617@elstar.local> In-Reply-To: <20160329173257.GB40617@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 21:00:49 -0000 Juergen, Looking at the text of section 3.3=20 The new multi-instance model doesn't seem to support this text. For example - can't just turn-on/turn-off suppression by setting enabled to= false and the unsuppression. Honestly it worked better when it was a single object with an enable and/or= endtime... BR, Tim -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Tuesday, March 29, 2016 12:33 PM To: KEN KO Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com Subject: Re: [lmap] Question on multiple outstanding suppressions You can still use suppressions as a panic button. You can have multiple pan= ic buttons if you want to (but you do not have to use it in that way). You = can have automatic pre-configured panic buttons (the new years evening exam= ple) but you do not have to use it that way. If you read the emails, you will note that we had not only panic buttons bu= t also a second mechanism to handle the loss of the controller. Instead of = having multiple hardwired mechanisms to disable 'things', the proposal back= then was to generalize _one_ mechanism so that it can do it all. The suppr= essions we have now makes code simpler, extensible and more powerful at the= same time. I do not see a good reason to go back. /js On Tue, Mar 29, 2016 at 05:22:55PM +0000, KEN KO wrote: > TR-304 (from BBF) and RFC 7594 both document suppression as a single inst= ance. It is intended to be used as a fairly blunt instrument, for instance = to prevent measurement traffic from exacerbating network congestion during = an unusual event. >=20 > From TR-304 section 5.2: "Suppression might be used when the measurement = system wants to minimize inessential traffic, for example after a major net= work incident. Only one suppression message can exist at a time in a given = MA. A new suppression message completely replaces the previous one." >=20 > From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is to= enable the Measurement System to eliminate Measurement Traffic, because th= ere is some unexpected network issue, for example. There may be other circ= umstances when Suppression is useful, for example, to eliminate inessential= Reporting traffic (even if there is no Measurement Traffic). >=20 > From RFC 7594 section 5.2.2: "However, Suppression information always rep= laces (rather than adds to) any previous Suppression information." >=20 > The idea in both documents was to provide a mechanism that was flexible i= n how tasks could be configured to react to it, but simple in how the "pani= c button" would be pushed in the case of a network event.=20 >=20 > From the archive link Juergen provided, it looks like the purpose of supp= ression in the information model has changed fairly dramatically, and that = it is now a more generic capability to disable tasks according to any of mu= ltiple schedules. I'm concerned that it may no longer provide the simple "p= anic button" that was intended. Do we really want to deviate in this way fr= om something that was defined specifically in the framework documents, whic= h after all are intended to provide guidance for more detailed documentatio= n? >=20 > Ken >=20 > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Tuesday, March 29, 2016 12:58 PM > To: Juergen Schoenwaelder; KEN KO > Cc: lmap@ietf.org; bs7652@att.com > Subject: RE: [lmap] Question on multiple outstanding suppressions >=20 > Juergen, >=20 > I suspect it was with good reason that the BBF wanted this as a single in= stance active at a time.=20 >=20 > Possibly Ken or Barbara could provide the reasoning. >=20 > Minimally I would think we would need to be able administratively enable/= disable a suppression object; that at least lets me shut them down temporar= ily. >=20 > BR, > Tim >=20 > -----Original Message----- > From: EXT Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, March 29, 2016 3:48 AM > To: KEN KO > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > Subject: Re: [lmap] Question on multiple outstanding suppressions >=20 > The original reasoning can be found here: >=20 > https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tbFI >=20 > Not being able to provision multiple suppressions seems a major limitatio= n to me. >=20 > /js >=20 > On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > > Tim, thanks for catching this. I'd also like to understand why lmap has= changed it. > > Ken > >=20 > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Thursday, March 24, 2016 9:57 AM > > To: lmap@ietf.org > > Cc: KEN KO; bs7652@att.com > > Subject: Question on multiple outstanding suppressions > >=20 > > Team, > >=20 > > I noticed that the information model has support for multiple suppressi= ons. > > With the current definition in the information model, it looks like the= re isn't any constraints on multiple suppression requests that can be activ= e at the same time. > >=20 > > I just wanted to a confirmation on this. We used to have just 1 suppres= sion object in an instruction. It looks like this changed in draft-07. > >=20 > > This actually conflicts with BBF TR-304 Section 5.2 where the text says= : > > Suppression is the temporary cessation of all or a subset of measuremen= t-related tasks. A Measurement Controller can send a suppress message to th= e MA that instructs the MA to temporarily suspend some or all of its schedu= led measurement-related tasks. Suppression ends either in response to an ex= plicit unsuppress message or at the time indicated in the suppress message.= Suppression might be used when the measurement system wants to minimize in= essential traffic, for example after a major network incident. Only one sup= pression message can exist at a time in a given MA. A new suppression messa= ge completely replaces the previous one. > >=20 > > So TR-304 would expect 1 suppression with an enable; this is quite diff= erent from the behavior that changed last November. > >=20 > >=20 > > Looking for guidance. > >=20 > > BR, > > Tim >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 30 00:41:44 2016 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 346D412D510 for ; Wed, 30 Mar 2016 00:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G11gbaxx_ppw for ; Wed, 30 Mar 2016 00:41:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD43112D15B for ; Wed, 30 Mar 2016 00:41:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AC37B1102; Wed, 30 Mar 2016 09:41:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VycBYF9FE_5J; Wed, 30 Mar 2016 09:41:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Mar 2016 09:41:39 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A7A420045; Wed, 30 Mar 2016 09:41:39 +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 qGYAcSNsSnnJ; Wed, 30 Mar 2016 09:41:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBAB420043; Wed, 30 Mar 2016 09:41:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D86BD3A62CCB; Wed, 30 Mar 2016 09:41:36 +0200 (CEST) Date: Wed, 30 Mar 2016 09:41:36 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160330074136.GB41707@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A60FF07@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329171809.GC40459@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614595@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A614595@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information model question on Events in the schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 07:41:44 -0000 On Tue, Mar 29, 2016 at 05:47:22PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I guess I will have to break this down abit by question in order for me to understand. > > Inline for the first clarification. > > -----Original Message----- > From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, March 29, 2016 12:18 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information model question on Events in the schedule > > On Thu, Mar 24, 2016 at 08:10:27PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > > > I was looking at the rework of the timers in the latest draft (-09). > > > > I am quite lost on this concept with respect to event start and end times and the schedule object. > > > > The schedule object had a timer object that said this schedule was active between this start time and this end time (for example if you used a calendar timer) or is active upon an interval if you had a periodic timer. That made sense to me. > > This is not correct. > Why do you say this is not correct. I have a schedule object that is associated with a calendar timer (as an example). That would mean in this instance the schedule would start and stop at that time - Period. What am I missing? Because this is not correct. Up to -07 there was only a single event object in ma-schedule-obj that indicates the start of a schedule. There was no end/duration for the schedule, this was added in -08. > > Now I have a schedule object that has a start parameter and optionally an (end parameter or interval parameter). The start and end parameters themselves are timer objects (e.g., for a calendar has a start and end time). > > Yep, this can be configured. > > > It would seem to me that all we need for a schedule is simply a timer that indicates when a schedule is suppose to start and end; as it is modeled today. > > > > So lets please go back to using the timers as it was before; it just seems simpler. > > No. The timers serve different purposes. There was no schedule end in earlier versions, Al Morton came up with the requirement to be able to control the duration of an active schedule. > > > If I am missing something maybe you can provide an example on paper where it doesn't work; because I think we are overloading event generation (timer going off) with the configuration of the time I expect a schedule to be active. Two different things... > > No, I believe this is clearly separated. Lets first talk about events and lets pick calendar events as an example (since you mentioned them). A calendar event specification can express that an event should be created lets say every day at 03:42:00. The optional ma-calendar-start and ma-calendar-end descripts say this: > > ma-calendar-start: The optional date and time at which > Schedules using this object are first > started. If not present it defaults to > immediate. > > ma-calendar-end: The optional date and time at which > Schedules using this object are last > started. If not present it defaults to > indefinite. > > If you do not set these fields, you fire an event every day at 03:42:00. By setting ma-calendar-start to 2016-04-01T00:00:00, the first time this calendar entry will fire an event is at > 2016-04-01T03:42:00 but nothing will happen before April 1st. If you set ma-calendar-end to 2016-05-01T00:00:00, the the last time this calendar entry will fire an event is at 2016-04-30T03:42:00. In other words, the ma-calendar-start and ma-calendar-end define the time interval in which the periodic event source is 'active'. > > Now lets talk about scheduled. A schedule is started when the start ma-schedule-start event takes place (and the schedule is not currently active). > > ma-schedule-start: An event object indicating when the > schedule starts. > > ma-schedule-end: An optional event object controlling > the forceful termination of scheduled > actions. When the event occurs, all > actions of the schedule will be forced > to terminate gracefully. > > ma-schedule-duration: An optional duration in seconds for the > schedule. All actions of the schedule > will be forced to terminate gracefully > after the duration number of seconds > past the start of the schedule. > > If you do not specify ma-schedule-end or ma-schedule-duration, the action will run until all actions have finished. If you set ma-schedule-duration, then you define a maximum running time for the schedule. If you set ma-schedule-end, then you define an event that causes the schedule to terminate when the event fires. > > Do you see that all these objects do have a specific purpose and do not overlap? Timer events are a specific point in time, schedules are started by an event and they either run until completion or they are optionally terminated after a certain duration or when an end event fires. > > /js > > -- > 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 nobody Wed Mar 30 00:50:07 2016 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 B37C312D11F for ; Wed, 30 Mar 2016 00:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYBPkkNyaj5b for ; Wed, 30 Mar 2016 00:50:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6D012D0A0 for ; Wed, 30 Mar 2016 00:50:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5216F11C8; Wed, 30 Mar 2016 09:50:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2-vTrIOykQm1; Wed, 30 Mar 2016 09:49:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Mar 2016 09:49:59 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A148920045; Wed, 30 Mar 2016 09:49:59 +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 mXRQ8nUIljBC; Wed, 30 Mar 2016 09:49:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3A6120043; Wed, 30 Mar 2016 09:49:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C1FB63A62D07; Wed, 30 Mar 2016 09:49:56 +0200 (CEST) Date: Wed, 30 Mar 2016 09:49:56 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160330074956.GC41707@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , KEN KO , "lmap@ietf.org" , "bs7652@att.com" References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329173257.GB40617@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "bs7652@att.com" , KEN KO , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 07:50:05 -0000 On Tue, Mar 29, 2016 at 08:31:06PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > Looking at the text of section 3.3 > The new multi-instance model doesn't seem to support this text. I disagree. > For example - can't just turn-on/turn-off suppression by setting enabled to false and the unsuppression. This question is orthogonal to the question whether there are multiple suppressions or just effectively two. > Honestly it worked better when it was a single object with an enable and/or endtime... > Why? There were two mechanisms, the traditional suppression and the reaction to loss of the controller. We now have a single mechanism that covers both cases and at the same time is more flexible and supports provisioned suppressions. The question whether we add enable/disable leafs in random places or everywhere is a separate question. When it comes to YANG, I am not a big fan, I rather would like to see a generic solution for this problem. /js > BR, > Tim > > -----Original Message----- > From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, March 29, 2016 12:33 PM > To: KEN KO > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > Subject: Re: [lmap] Question on multiple outstanding suppressions > > You can still use suppressions as a panic button. You can have multiple panic buttons if you want to (but you do not have to use it in that way). You can have automatic pre-configured panic buttons (the new years evening example) but you do not have to use it that way. > > If you read the emails, you will note that we had not only panic buttons but also a second mechanism to handle the loss of the controller. Instead of having multiple hardwired mechanisms to disable 'things', the proposal back then was to generalize _one_ mechanism so that it can do it all. The suppressions we have now makes code simpler, extensible and more powerful at the same time. I do not see a good reason to go back. > > /js > > On Tue, Mar 29, 2016 at 05:22:55PM +0000, KEN KO wrote: > > TR-304 (from BBF) and RFC 7594 both document suppression as a single instance. It is intended to be used as a fairly blunt instrument, for instance to prevent measurement traffic from exacerbating network congestion during an unusual event. > > > > From TR-304 section 5.2: "Suppression might be used when the measurement system wants to minimize inessential traffic, for example after a major network incident. Only one suppression message can exist at a time in a given MA. A new suppression message completely replaces the previous one." > > > > From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is to enable the Measurement System to eliminate Measurement Traffic, because there is some unexpected network issue, for example. There may be other circumstances when Suppression is useful, for example, to eliminate inessential Reporting traffic (even if there is no Measurement Traffic). > > > > From RFC 7594 section 5.2.2: "However, Suppression information always replaces (rather than adds to) any previous Suppression information." > > > > The idea in both documents was to provide a mechanism that was flexible in how tasks could be configured to react to it, but simple in how the "panic button" would be pushed in the case of a network event. > > > > From the archive link Juergen provided, it looks like the purpose of suppression in the information model has changed fairly dramatically, and that it is now a more generic capability to disable tasks according to any of multiple schedules. I'm concerned that it may no longer provide the simple "panic button" that was intended. Do we really want to deviate in this way from something that was defined specifically in the framework documents, which after all are intended to provide guidance for more detailed documentation? > > > > Ken > > > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Tuesday, March 29, 2016 12:58 PM > > To: Juergen Schoenwaelder; KEN KO > > Cc: lmap@ietf.org; bs7652@att.com > > Subject: RE: [lmap] Question on multiple outstanding suppressions > > > > Juergen, > > > > I suspect it was with good reason that the BBF wanted this as a single instance active at a time. > > > > Possibly Ken or Barbara could provide the reasoning. > > > > Minimally I would think we would need to be able administratively enable/disable a suppression object; that at least lets me shut them down temporarily. > > > > BR, > > Tim > > > > -----Original Message----- > > From: EXT Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, March 29, 2016 3:48 AM > > To: KEN KO > > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > > Subject: Re: [lmap] Question on multiple outstanding suppressions > > > > The original reasoning can be found here: > > > > https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tbFI > > > > Not being able to provision multiple suppressions seems a major limitation to me. > > > > /js > > > > On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > > > Tim, thanks for catching this. I'd also like to understand why lmap has changed it. > > > Ken > > > > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Thursday, March 24, 2016 9:57 AM > > > To: lmap@ietf.org > > > Cc: KEN KO; bs7652@att.com > > > Subject: Question on multiple outstanding suppressions > > > > > > Team, > > > > > > I noticed that the information model has support for multiple suppressions. > > > With the current definition in the information model, it looks like there isn't any constraints on multiple suppression requests that can be active at the same time. > > > > > > I just wanted to a confirmation on this. We used to have just 1 suppression object in an instruction. It looks like this changed in draft-07. > > > > > > This actually conflicts with BBF TR-304 Section 5.2 where the text says: > > > Suppression is the temporary cessation of all or a subset of measurement-related tasks. A Measurement Controller can send a suppress message to the MA that instructs the MA to temporarily suspend some or all of its scheduled measurement-related tasks. Suppression ends either in response to an explicit unsuppress message or at the time indicated in the suppress message. Suppression might be used when the measurement system wants to minimize inessential traffic, for example after a major network incident. Only one suppression message can exist at a time in a given MA. A new suppression message completely replaces the previous one. > > > > > > So TR-304 would expect 1 suppression with an enable; this is quite different from the behavior that changed last November. > > > > > > > > > Looking for guidance. > > > > > > BR, > > > Tim > > > > > _______________________________________________ > > > 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 30 04:49:39 2016 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 CD0A012D658 for ; Wed, 30 Mar 2016 04:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAtVEm1fEeSs for ; Wed, 30 Mar 2016 04:49:35 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C2512D66F for ; Wed, 30 Mar 2016 04:49:28 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id C022446406D62; Wed, 30 Mar 2016 11:49:25 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u2UBnQmL025239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2016 11:49:26 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u2UBnQNp006329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Mar 2016 11:49:26 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 30 Mar 2016 07:49:26 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information model question on Events in the schedule Thread-Index: AQHRid8Co6YkaVHid0u0DyBcFtvo5p9wsZEAgAEs6wD///4NcA== Date: Wed, 30 Mar 2016 11:49:24 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A61A2D2@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A60FF07@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329171809.GC40459@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614595@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160330074136.GB41707@elstar.local> In-Reply-To: <20160330074136.GB41707@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 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information model question on Events in the schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 11:49:38 -0000 Juergen, I think again there is overload in the event. In -05 there were timing objects. These timing objects were assigned to a schedule. The Calendar and periodi= c timing object has a start and end date. The one-off and Immediate were on= e time. At that revision everything was cored in terms of scheduling a task.=20 Then things got conflated with an event concept in -06 but the timing objec= ts still have a start and end time.=20 In the case of the schedule with a calendar/periodic "event" this would be = the start and stop time of the schedule. On the single schedule object: That is incorrect the calendar object has a = start and end date. I do not understand why you say it doesn't have a end d= ate.=20 Is it that you expect different/numerous event instances for a single sched= ule (each time the schedule timer fires). If so I think that is what was co= nflated? If so the original intent was to simply have a timer object that = described when a schedule was active not the actual event that it did fire. BR, Tim -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Wednesday, March 30, 2016 2:42 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information model question on Events in the schedule On Tue, Mar 29, 2016 at 05:47:22PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > I guess I will have to break this down abit by question in order for me t= o understand. >=20 > Inline for the first clarification. >=20 > -----Original Message----- > From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university= .de]=20 > Sent: Tuesday, March 29, 2016 12:18 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information model question on Events in the schedule >=20 > On Thu, Mar 24, 2016 at 08:10:27PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Juergen, > >=20 > > I was looking at the rework of the timers in the latest draft (-09). > >=20 > > I am quite lost on this concept with respect to event start and end tim= es and the schedule object. > >=20 > > The schedule object had a timer object that said this schedule was acti= ve between this start time and this end time (for example if you used a cal= endar timer) or is active upon an interval if you had a periodic timer. Tha= t made sense to me. >=20 > This is not correct. > Why do you say this is not correct. I have a schedule object that i= s associated with a calendar timer (as an example). That would mean in this= instance the schedule would start and stop at that time - Period. What am = I missing? Because this is not correct. Up to -07 there was only a single event object= in ma-schedule-obj that indicates the start of a schedule. There was no en= d/duration for the schedule, this was added in -08. > > Now I have a schedule object that has a start parameter and optionally = an (end parameter or interval parameter). The start and end parameters them= selves are timer objects (e.g., for a calendar has a start and end time). >=20 > Yep, this can be configured. >=20 > > It would seem to me that all we need for a schedule is simply a timer t= hat indicates when a schedule is suppose to start and end; as it is modeled= today. > >=20 > > So lets please go back to using the timers as it was before; it just se= ems simpler. >=20 > No. The timers serve different purposes. There was no schedule end in ear= lier versions, Al Morton came up with the requirement to be able to control= the duration of an active schedule. >=20 > > If I am missing something maybe you can provide an example on paper whe= re it doesn't work; because I think we are overloading event generation (ti= mer going off) with the configuration of the time I expect a schedule to be= active. Two different things... >=20 > No, I believe this is clearly separated. Lets first talk about events and= lets pick calendar events as an example (since you mentioned them). A cale= ndar event specification can express that an event should be created lets s= ay every day at 03:42:00. The optional ma-calendar-start and ma-calendar-en= d descripts say this: >=20 > ma-calendar-start: The optional date and time at which > Schedules using this object are first > started. If not present it defaults to > immediate. >=20 > ma-calendar-end: The optional date and time at which > Schedules using this object are last > started. If not present it defaults to > indefinite. >=20 > If you do not set these fields, you fire an event every day at 03:42:00. = By setting ma-calendar-start to 2016-04-01T00:00:00, the first time this ca= lendar entry will fire an event is at > 2016-04-01T03:42:00 but nothing will happen before April 1st. If you set = ma-calendar-end to 2016-05-01T00:00:00, the the last time this calendar ent= ry will fire an event is at 2016-04-30T03:42:00. In other words, the ma-cal= endar-start and ma-calendar-end define the time interval in which the perio= dic event source is 'active'. >=20 > Now lets talk about scheduled. A schedule is started when the start ma-sc= hedule-start event takes place (and the schedule is not currently active).= =20 >=20 > ma-schedule-start: An event object indicating when the > schedule starts. >=20 > ma-schedule-end: An optional event object controlling > the forceful termination of scheduled > actions. When the event occurs, all > actions of the schedule will be forced > to terminate gracefully. >=20 > ma-schedule-duration: An optional duration in seconds for the > schedule. All actions of the schedule > will be forced to terminate gracefully > after the duration number of seconds > past the start of the schedule. >=20 > If you do not specify ma-schedule-end or ma-schedule-duration, the action= will run until all actions have finished. If you set ma-schedule-duration,= then you define a maximum running time for the schedule. If you set ma-sch= edule-end, then you define an event that causes the schedule to terminate w= hen the event fires. >=20 > Do you see that all these objects do have a specific purpose and do not o= verlap? Timer events are a specific point in time, schedules are started by= an event and they either run until completion or they are optionally termi= nated after a certain duration or when an end event fires. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 30 05:09:00 2016 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 BC6E812E042 for ; Wed, 30 Mar 2016 05:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qzJgWs544pB for ; Wed, 30 Mar 2016 05:08:53 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE94A12DBFE for ; Wed, 30 Mar 2016 05:07:03 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id B97808B61AC05; Wed, 30 Mar 2016 12:07:00 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u2UC72RR003885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2016 12:07:02 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u2UC6dr1016003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Mar 2016 12:07:02 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Wed, 30 Mar 2016 08:07:00 -0400 From: "Carey, Timothy (Nokia - US)" To: "Carey, Timothy (Nokia - US)" , "Juergen Schoenwaelder" Thread-Topic: [lmap] Information model question on Events in the schedule Thread-Index: AQHRid8Co6YkaVHid0u0DyBcFtvo5p9wsZEAgAEs6wD///4NcIAACNVw Date: Wed, 30 Mar 2016 12:06:59 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A61A335@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A60FF07@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329171809.GC40459@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614595@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160330074136.GB41707@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 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information model question on Events in the schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 12:09:00 -0000 Sorry - meant correct not "cored" -----Original Message----- From: Carey, Timothy (Nokia - US)=20 Sent: Wednesday, March 30, 2016 6:49 AM To: 'Juergen Schoenwaelder' Cc: lmap@ietf.org Subject: RE: [lmap] Information model question on Events in the schedule Juergen, I think again there is overload in the event. In -05 there were timing objects. These timing objects were assigned to a schedule. The Calendar and periodi= c timing object has a start and end date. The one-off and Immediate were on= e time. At that revision everything was cored in terms of scheduling a task.=20 Then things got conflated with an event concept in -06 but the timing objec= ts still have a start and end time.=20 In the case of the schedule with a calendar/periodic "event" this would be = the start and stop time of the schedule. On the single schedule object: That is incorrect the calendar object has a = start and end date. I do not understand why you say it doesn't have a end d= ate.=20 Is it that you expect different/numerous event instances for a single sched= ule (each time the schedule timer fires). If so I think that is what was co= nflated? If so the original intent was to simply have a timer object that = described when a schedule was active not the actual event that it did fire. BR, Tim -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Wednesday, March 30, 2016 2:42 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information model question on Events in the schedule On Tue, Mar 29, 2016 at 05:47:22PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > I guess I will have to break this down abit by question in order for me t= o understand. >=20 > Inline for the first clarification. >=20 > -----Original Message----- > From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university= .de]=20 > Sent: Tuesday, March 29, 2016 12:18 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information model question on Events in the schedule >=20 > On Thu, Mar 24, 2016 at 08:10:27PM +0000, Carey, Timothy (Nokia - US) wro= te: > > Juergen, > >=20 > > I was looking at the rework of the timers in the latest draft (-09). > >=20 > > I am quite lost on this concept with respect to event start and end tim= es and the schedule object. > >=20 > > The schedule object had a timer object that said this schedule was acti= ve between this start time and this end time (for example if you used a cal= endar timer) or is active upon an interval if you had a periodic timer. Tha= t made sense to me. >=20 > This is not correct. > Why do you say this is not correct. I have a schedule object that i= s associated with a calendar timer (as an example). That would mean in this= instance the schedule would start and stop at that time - Period. What am = I missing? Because this is not correct. Up to -07 there was only a single event object= in ma-schedule-obj that indicates the start of a schedule. There was no en= d/duration for the schedule, this was added in -08. > > Now I have a schedule object that has a start parameter and optionally = an (end parameter or interval parameter). The start and end parameters them= selves are timer objects (e.g., for a calendar has a start and end time). >=20 > Yep, this can be configured. >=20 > > It would seem to me that all we need for a schedule is simply a timer t= hat indicates when a schedule is suppose to start and end; as it is modeled= today. > >=20 > > So lets please go back to using the timers as it was before; it just se= ems simpler. >=20 > No. The timers serve different purposes. There was no schedule end in ear= lier versions, Al Morton came up with the requirement to be able to control= the duration of an active schedule. >=20 > > If I am missing something maybe you can provide an example on paper whe= re it doesn't work; because I think we are overloading event generation (ti= mer going off) with the configuration of the time I expect a schedule to be= active. Two different things... >=20 > No, I believe this is clearly separated. Lets first talk about events and= lets pick calendar events as an example (since you mentioned them). A cale= ndar event specification can express that an event should be created lets s= ay every day at 03:42:00. The optional ma-calendar-start and ma-calendar-en= d descripts say this: >=20 > ma-calendar-start: The optional date and time at which > Schedules using this object are first > started. If not present it defaults to > immediate. >=20 > ma-calendar-end: The optional date and time at which > Schedules using this object are last > started. If not present it defaults to > indefinite. >=20 > If you do not set these fields, you fire an event every day at 03:42:00. = By setting ma-calendar-start to 2016-04-01T00:00:00, the first time this ca= lendar entry will fire an event is at > 2016-04-01T03:42:00 but nothing will happen before April 1st. If you set = ma-calendar-end to 2016-05-01T00:00:00, the the last time this calendar ent= ry will fire an event is at 2016-04-30T03:42:00. In other words, the ma-cal= endar-start and ma-calendar-end define the time interval in which the perio= dic event source is 'active'. >=20 > Now lets talk about scheduled. A schedule is started when the start ma-sc= hedule-start event takes place (and the schedule is not currently active).= =20 >=20 > ma-schedule-start: An event object indicating when the > schedule starts. >=20 > ma-schedule-end: An optional event object controlling > the forceful termination of scheduled > actions. When the event occurs, all > actions of the schedule will be forced > to terminate gracefully. >=20 > ma-schedule-duration: An optional duration in seconds for the > schedule. All actions of the schedule > will be forced to terminate gracefully > after the duration number of seconds > past the start of the schedule. >=20 > If you do not specify ma-schedule-end or ma-schedule-duration, the action= will run until all actions have finished. If you set ma-schedule-duration,= then you define a maximum running time for the schedule. If you set ma-sch= edule-end, then you define an event that causes the schedule to terminate w= hen the event fires. >=20 > Do you see that all these objects do have a specific purpose and do not o= verlap? Timer events are a specific point in time, schedules are started by= an event and they either run until completion or they are optionally termi= nated after a certain duration or when an end event fires. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 30 05:10:43 2016 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 2E2F512E0CC for ; Wed, 30 Mar 2016 05:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqH3pVvUuVzn for ; Wed, 30 Mar 2016 05:10:38 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED3A12DED3 for ; Wed, 30 Mar 2016 05:08:05 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id A782D399CEC49; Wed, 30 Mar 2016 12:05:01 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u2UC53eG024468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2016 12:05:03 GMT 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 u2UC4xgm016054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Mar 2016 12:05:00 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 30 Mar 2016 08:05:00 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUgAAFPfwAPbj/QAACBWu0AAJ4/OAAABZtYAAAkhGkAAbpcEAAAACS0A= Date: Wed, 30 Mar 2016 12:04:59 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A61A320@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329173257.GB40617@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160330074956.GC41707@elstar.local> In-Reply-To: <20160330074956.GC41707@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 Archived-At: Cc: "bs7652@att.com" , KEN KO , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 12:10:41 -0000 Juergen, Controller timeout and a temporary suppression might need to suppress diffe= rent actions/tasks - correct? Is this why you added suppression as multi-in= stance object? BR, Tim -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Wednesday, March 30, 2016 2:50 AM To: Carey, Timothy (Nokia - US) Cc: KEN KO; lmap@ietf.org; bs7652@att.com Subject: Re: [lmap] Question on multiple outstanding suppressions On Tue, Mar 29, 2016 at 08:31:06PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > Looking at the text of section 3.3 > The new multi-instance model doesn't seem to support this text. I disagree. =20 > For example - can't just turn-on/turn-off suppression by setting enabled = to false and the unsuppression. This question is orthogonal to the question whether there are multiple supp= ressions or just effectively two. > Honestly it worked better when it was a single object with an enable and/= or endtime... > Why? There were two mechanisms, the traditional suppression and the reactio= n to loss of the controller. We now have a single mechanism that covers bot= h cases and at the same time is more flexible and supports provisioned supp= ressions. The question whether we add enable/disable leafs in random places or everyw= here is a separate question. When it comes to YANG, I am not a big fan, I r= ather would like to see a generic solution for this problem. /js > BR, > Tim >=20 > -----Original Message----- > From: EXT Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, March 29, 2016 12:33 PM > To: KEN KO > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > Subject: Re: [lmap] Question on multiple outstanding suppressions >=20 > You can still use suppressions as a panic button. You can have multiple p= anic buttons if you want to (but you do not have to use it in that way). Yo= u can have automatic pre-configured panic buttons (the new years evening ex= ample) but you do not have to use it that way. >=20 > If you read the emails, you will note that we had not only panic buttons = but also a second mechanism to handle the loss of the controller. Instead o= f having multiple hardwired mechanisms to disable 'things', the proposal ba= ck then was to generalize _one_ mechanism so that it can do it all. The sup= pressions we have now makes code simpler, extensible and more powerful at t= he same time. I do not see a good reason to go back. >=20 > /js >=20 > On Tue, Mar 29, 2016 at 05:22:55PM +0000, KEN KO wrote: > > TR-304 (from BBF) and RFC 7594 both document suppression as a single in= stance. It is intended to be used as a fairly blunt instrument, for instanc= e to prevent measurement traffic from exacerbating network congestion durin= g an unusual event. > >=20 > > From TR-304 section 5.2: "Suppression might be used when the measuremen= t system wants to minimize inessential traffic, for example after a major n= etwork incident. Only one suppression message can exist at a time in a give= n MA. A new suppression message completely replaces the previous one." > >=20 > > From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is = to enable the Measurement System to eliminate Measurement Traffic, because = there is some unexpected network issue, for example. There may be other ci= rcumstances when Suppression is useful, for example, to eliminate inessenti= al Reporting traffic (even if there is no Measurement Traffic). > >=20 > > From RFC 7594 section 5.2.2: "However, Suppression information always r= eplaces (rather than adds to) any previous Suppression information." > >=20 > > The idea in both documents was to provide a mechanism that was flexible= in how tasks could be configured to react to it, but simple in how the "pa= nic button" would be pushed in the case of a network event.=20 > >=20 > > From the archive link Juergen provided, it looks like the purpose of su= ppression in the information model has changed fairly dramatically, and tha= t it is now a more generic capability to disable tasks according to any of = multiple schedules. I'm concerned that it may no longer provide the simple = "panic button" that was intended. Do we really want to deviate in this way = from something that was defined specifically in the framework documents, wh= ich after all are intended to provide guidance for more detailed documentat= ion? > >=20 > > Ken > >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Tuesday, March 29, 2016 12:58 PM > > To: Juergen Schoenwaelder; KEN KO > > Cc: lmap@ietf.org; bs7652@att.com > > Subject: RE: [lmap] Question on multiple outstanding suppressions > >=20 > > Juergen, > >=20 > > I suspect it was with good reason that the BBF wanted this as a single = instance active at a time.=20 > >=20 > > Possibly Ken or Barbara could provide the reasoning. > >=20 > > Minimally I would think we would need to be able administratively enabl= e/disable a suppression object; that at least lets me shut them down tempor= arily. > >=20 > > BR, > > Tim > >=20 > > -----Original Message----- > > From: EXT Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, March 29, 2016 3:48 AM > > To: KEN KO > > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > > Subject: Re: [lmap] Question on multiple outstanding suppressions > >=20 > > The original reasoning can be found here: > >=20 > > https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tb > > FI > >=20 > > Not being able to provision multiple suppressions seems a major limitat= ion to me. > >=20 > > /js > >=20 > > On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > > > Tim, thanks for catching this. I'd also like to understand why lmap h= as changed it. > > > Ken > > >=20 > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Thursday, March 24, 2016 9:57 AM > > > To: lmap@ietf.org > > > Cc: KEN KO; bs7652@att.com > > > Subject: Question on multiple outstanding suppressions > > >=20 > > > Team, > > >=20 > > > I noticed that the information model has support for multiple suppres= sions. > > > With the current definition in the information model, it looks like t= here isn't any constraints on multiple suppression requests that can be act= ive at the same time. > > >=20 > > > I just wanted to a confirmation on this. We used to have just 1 suppr= ession object in an instruction. It looks like this changed in draft-07. > > >=20 > > > This actually conflicts with BBF TR-304 Section 5.2 where the text sa= ys: > > > Suppression is the temporary cessation of all or a subset of measurem= ent-related tasks. A Measurement Controller can send a suppress message to = the MA that instructs the MA to temporarily suspend some or all of its sche= duled measurement-related tasks. Suppression ends either in response to an = explicit unsuppress message or at the time indicated in the suppress messag= e. Suppression might be used when the measurement system wants to minimize = inessential traffic, for example after a major network incident. Only one s= uppression message can exist at a time in a given MA. A new suppression mes= sage completely replaces the previous one. > > >=20 > > > So TR-304 would expect 1 suppression with an enable; this is quite di= fferent from the behavior that changed last November. > > >=20 > > >=20 > > > Looking for guidance. > > >=20 > > > BR, > > > Tim > >=20 > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > >=20 > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 30 05:10:46 2016 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 B6A6812E0D3 for ; Wed, 30 Mar 2016 05:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Eez2bHtUYpa for ; Wed, 30 Mar 2016 05:10:36 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC8A12DECC for ; Wed, 30 Mar 2016 05:08:05 -0700 (PDT) Date: Wed, 30 Mar 2016 12:08:02 +0000 From: "timothy.carey" To: mailrelay@alcatel-lucent.com, j.schoenwaelder@jacobs-university.de, KEN.KO@adtran.com, lmap@ietf.org, bs7652@att.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="knzbfhXcf33L7YMn" Content-Disposition: inline Message-Id: <20160330120805.1EC8A12DECC@ietfa.amsl.com> Archived-At: Subject: [lmap] ATTENTION: Message could not be processed X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 12:10:42 -0000 --knzbfhXcf33L7YMn Content-Type: text/plain; charset=utf-8 Content-Disposition: inline The message sent to j.schoenwaelder@jacobs-university.de KEN.KO@adtran.com lmap@ietf.org bs7652@att.com on Wed Mar 30 12:05:01 2016 UTC may be invalid. Sender: timothy.carey@nokia.com Message subject: RE: [lmap] Question on multiple outstanding suppressions If this message is not junk mail please contact the sender. --knzbfhXcf33L7YMn-- From nobody Wed Mar 30 06:47:44 2016 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 27AE812D1A7 for ; Wed, 30 Mar 2016 06:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06BBcnrRVuGw for ; Wed, 30 Mar 2016 06:47:40 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [200.160.4.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8B412D6FE for ; Wed, 30 Mar 2016 06:45:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 7BFA918F14C; Wed, 30 Mar 2016 10:45:08 -0300 (BRT) X-Virus-Scanned: Debian amavisd-new at mail.nic.br Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI3GvQN-7Opu; Wed, 30 Mar 2016 10:45:05 -0300 (BRT) Received: from 5.140.net.registro.br (unknown [IPv6:2001:12ff:0:5::140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: holger@nic.br) by mail.nic.br (Postfix) with ESMTPSA id 73B0918F198; Wed, 30 Mar 2016 10:44:59 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1459345499; bh=3DTYa2aAsWS0VYHmiErRM/eya6Mb/rPXZiXrpv3rSQg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mLWKonvw6h+R81arVVzmXRfWpCvcacjUSSGkt7UsdtKhTyfLdRq7/X7bxAvIDu6Wg kyYe3yy4vzqEILcOoBo49vWROVSM4Hg4RUYS+f3aG1Z3erryW7TUxNqdxDw2ujKYRJ G850ucgh0cGqK9Kz7O+VOcDiD2y0UIhuMMuYgBz8= Content-Type: multipart/alternative; boundary="Apple-Mail=_4699E9DF-14C8-4477-A323-05034DB2CFEF" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Holger Wiehen In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA751A3F18@AZ-FFEXMB04.global.avaya.com> Date: Wed, 30 Mar 2016 10:45:04 -0300 Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA751A3F18@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.3124) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br 73B0918F198 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] agenda and meeting logistics for IETF 95 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 13:47:42 -0000 --Apple-Mail=_4699E9DF-14C8-4477-A323-05034DB2CFEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dan. I am going to attend the WG meeting in Buenos Aires, and would like to = contribute as a note taker. Regards, Holger Wiehen. =E2=80=94 holger@nic.br +55 11 5509-3537 > On Mar 28, 2016, at 9:20 AM, Romascanu, Dan (Dan) = wrote: >=20 > Hi, > =20 > The agenda of the WG meeting at IETF 95 is available at = https://datatracker.ietf.org/meeting/95/agenda/lmap/ = . If there are any = last minute requests for new items or changes please let us know today! > =20 > Remote participation is possible. Right now we have only Juergen = registered as a remote participant. If there are more requests, please = let us know. The Meetecho team may contact the remote participants = before the meeting to check connectivity and optimize quality.=20 > =20 > As in all meetings, we need two note takers and one jabber scribe. = Please volunteer! > =20 > Thanks and Regards, > =20 > Jason and Dan > =20 > =20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap = --Apple-Mail=_4699E9DF-14C8-4477-A323-05034DB2CFEF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Dan.

I = am going to attend the WG meeting in Buenos Aires, and would like to = contribute as a note taker.


Regards,

Holger Wiehen.

=E2=80=94
holger@nic.br
+55 11 = 5509-3537


On = Mar 28, 2016, at 9:20 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> = wrote:

Hi,
 
The = agenda of the WG meeting at IETF 95 is available at https://datatracker.ietf.org/meeting/95/agenda/lmap/. If = there are any last minute requests for new items or changes please let = us know today!
 
Remote participation is possible. Right now we have only = Juergen registered as a remote participant. If there are more requests, = please let us know. The Meetecho team may contact the remote = participants before the meeting to check connectivity and optimize = quality. 
 
As in all = meetings, we need two note takers and one jabber scribe. Please = volunteer!
 
Thanks and Regards,
 
Jason and Dan
 
 
_______________________________________________
lmap mailing = list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap

= --Apple-Mail=_4699E9DF-14C8-4477-A323-05034DB2CFEF-- From nobody Wed Mar 30 07:06:47 2016 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 32C5912D5E4 for ; Wed, 30 Mar 2016 07:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IndxzIE7Gy4 for ; Wed, 30 Mar 2016 07:06:43 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BFC12D561 for ; Wed, 30 Mar 2016 06:59:37 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id u2UDxWVs026494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Mar 2016 08:59:32 -0500 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 1FC691E0060; Wed, 30 Mar 2016 07:59:27 -0600 (MDT) Received: from lxdnp32k.corp.intranet (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 0477F1E0068; Wed, 30 Mar 2016 07:59:27 -0600 (MDT) Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id u2UDxQ5X024188; Wed, 30 Mar 2016 07:59:26 -0600 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id u2UDxQ3L024182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Mar 2016 07:59:26 -0600 Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0195.001; Wed, 30 Mar 2016 08:59:25 -0500 From: "Bugenhagen, Michael K" To: "'Carey, Timothy (Nokia - US)'" , "Juergen Schoenwaelder" , KEN KO Thread-Topic: [lmap] Question on multiple outstanding suppressions Thread-Index: AdGF3V4xmgrf/a4tTNWOZo/M3lKnUgAAFPfwAPj8bgAAER67AAAKO3Ag//+3yYCAADHGAP//MO0w Date: Wed, 30 Mar 2016 13:59:25 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F77012A60F5F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329084814.GA38204@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A614422@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160329173257.GB40617@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A619A6B@US70UWXCHMBA05.zam.alcatel-lucent.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-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] Question on multiple outstanding suppressions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 14:06:46 -0000 It would be nice if we made "suppression" extensible. Operationally when finding something has been "taken out of service" - on= e often what's to know ... WHY - before turning on the water again. To that end it would be very "operationally" valuable to have some TLV or e= ven standard "why it's suppressed" tracking. A few examples I have run into in the field (used when I was Op's)... 1) Network Op's suppression - Meaning the network guys shut this done, and = they should be the only one to open it up... 2) The tester shut itself down - multiple reason why it might, but it's mo= re important to know the end point decided to stop.. 3) Single test suppressed (maybe I tested to a point, and it failed hard an= d I just want to stop doing worthless sequential testing). - Here if I'm testing a path, and can't even get a= good test I my own network, well maybe I should stop trying to test past a= failure. Not sure how this might help, but knowing those 3 scenarios makes Op's work= much more effective... so having these types of "states" of knowledge abou= t why things stopped are rather valuable... Not sure if there is one, but a "suppression state machine" picture tha= t had these types of things would be pretty cool.. Regards, Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Noki= a - US) Sent: Tuesday, March 29, 2016 3:31 PM To: Juergen Schoenwaelder; KEN KO Cc: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] Question on multiple outstanding suppressions Juergen, Looking at the text of section 3.3 The new multi-instance model doesn't seem to support this text. For example - can't just turn-on/turn-off suppression by setting enabled to= false and the unsuppression. Honestly it worked better when it was a single object with an enable and/or= endtime... BR, Tim -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e] Sent: Tuesday, March 29, 2016 12:33 PM To: KEN KO Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com Subject: Re: [lmap] Question on multiple outstanding suppressions You can still use suppressions as a panic button. You can have multiple pan= ic buttons if you want to (but you do not have to use it in that way). You = can have automatic pre-configured panic buttons (the new years evening exam= ple) but you do not have to use it that way. If you read the emails, you will note that we had not only panic buttons bu= t also a second mechanism to handle the loss of the controller. Instead of = having multiple hardwired mechanisms to disable 'things', the proposal back= then was to generalize _one_ mechanism so that it can do it all. The suppr= essions we have now makes code simpler, extensible and more powerful at the= same time. I do not see a good reason to go back. /js On Tue, Mar 29, 2016 at 05:22:55PM +0000, KEN KO wrote: > TR-304 (from BBF) and RFC 7594 both document suppression as a single inst= ance. It is intended to be used as a fairly blunt instrument, for instance = to prevent measurement traffic from exacerbating network congestion during = an unusual event. > > From TR-304 section 5.2: "Suppression might be used when the measurement = system wants to minimize inessential traffic, for example after a major net= work incident. Only one suppression message can exist at a time in a given = MA. A new suppression message completely replaces the previous one." > > From RFC 7594 section 5.2.2.1: "The main motivation for Suppression is to= enable the Measurement System to eliminate Measurement Traffic, because th= ere is some unexpected network issue, for example. There may be other circ= umstances when Suppression is useful, for example, to eliminate inessential= Reporting traffic (even if there is no Measurement Traffic). > > From RFC 7594 section 5.2.2: "However, Suppression information always rep= laces (rather than adds to) any previous Suppression information." > > The idea in both documents was to provide a mechanism that was flexible i= n how tasks could be configured to react to it, but simple in how the "pani= c button" would be pushed in the case of a network event. > > From the archive link Juergen provided, it looks like the purpose of supp= ression in the information model has changed fairly dramatically, and that = it is now a more generic capability to disable tasks according to any of mu= ltiple schedules. I'm concerned that it may no longer provide the simple "p= anic button" that was intended. Do we really want to deviate in this way fr= om something that was defined specifically in the framework documents, whic= h after all are intended to provide guidance for more detailed documentatio= n? > > Ken > > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Tuesday, March 29, 2016 12:58 PM > To: Juergen Schoenwaelder; KEN KO > Cc: lmap@ietf.org; bs7652@att.com > Subject: RE: [lmap] Question on multiple outstanding suppressions > > Juergen, > > I suspect it was with good reason that the BBF wanted this as a single in= stance active at a time. > > Possibly Ken or Barbara could provide the reasoning. > > Minimally I would think we would need to be able administratively enable/= disable a suppression object; that at least lets me shut them down temporar= ily. > > BR, > Tim > > -----Original Message----- > From: EXT Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, March 29, 2016 3:48 AM > To: KEN KO > Cc: Carey, Timothy (Nokia - US); lmap@ietf.org; bs7652@att.com > Subject: Re: [lmap] Question on multiple outstanding suppressions > > The original reasoning can be found here: > > https://mailarchive.ietf.org/arch/msg/lmap/ptg-TcdfMuVHM93PWisj4u-tbFI > > Not being able to provision multiple suppressions seems a major limitatio= n to me. > > /js > > On Thu, Mar 24, 2016 at 03:00:27PM +0000, KEN KO wrote: > > Tim, thanks for catching this. I'd also like to understand why lmap has= changed it. > > Ken > > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Thursday, March 24, 2016 9:57 AM > > To: lmap@ietf.org > > Cc: KEN KO; bs7652@att.com > > Subject: Question on multiple outstanding suppressions > > > > Team, > > > > I noticed that the information model has support for multiple suppressi= ons. > > With the current definition in the information model, it looks like the= re isn't any constraints on multiple suppression requests that can be activ= e at the same time. > > > > I just wanted to a confirmation on this. We used to have just 1 suppres= sion object in an instruction. It looks like this changed in draft-07. > > > > This actually conflicts with BBF TR-304 Section 5.2 where the text says= : > > Suppression is the temporary cessation of all or a subset of measuremen= t-related tasks. A Measurement Controller can send a suppress message to th= e MA that instructs the MA to temporarily suspend some or all of its schedu= led measurement-related tasks. Suppression ends either in response to an ex= plicit unsuppress message or at the time indicated in the suppress message.= Suppression might be used when the measurement system wants to minimize in= essential traffic, for example after a major network incident. Only one sup= pression message can exist at a time in a given MA. A new suppression messa= ge completely replaces the previous one. > > > > So TR-304 would expect 1 suppression with an enable; this is quite diff= erent from the behavior that changed last November. > > > > > > Looking for guidance. > > > > BR, > > Tim > > > _______________________________________________ > > 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 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Thu Mar 31 03:23:18 2016 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 DB2A712D584 for ; Thu, 31 Mar 2016 03:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.93 X-Spam-Level: X-Spam-Status: No, score=-6.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwPqGgiDIj22 for ; Thu, 31 Mar 2016 03:23:11 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332CA12D591 for ; Thu, 31 Mar 2016 03:23:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AjAgDi+fxW/yYyC4dDGh2CaytTfQa5AIIPAQ2BZAwXCoVsAhyBIjgUAQEBAQEBAWUcC4RBAQEBAQMSERFRBgEIDQQEAQEDAgYdAwIEMBQBBgEBBQQBBBMIGogFAQ0soEiFEopLkSABAQEBAQUBAQEBAQEBAQEBARV8hSOERYQ+FoIyOBMYgisFjUeKKwGFcol7ToN/gxyFPo8VHgEBQoNnbAEBh20BfQEBAQ X-IPAS-Result: A2AjAgDi+fxW/yYyC4dDGh2CaytTfQa5AIIPAQ2BZAwXCoVsAhyBIjgUAQEBAQEBAWUcC4RBAQEBAQMSERFRBgEIDQQEAQEDAgYdAwIEMBQBBgEBBQQBBBMIGogFAQ0soEiFEopLkSABAQEBAQUBAQEBAQEBAQEBARV8hSOERYQ+FoIyOBMYgisFjUeKKwGFcol7ToN/gxyFPo8VHgEBQoNnbAEBh20BfQEBAQ X-IronPort-AV: E=Sophos;i="5.24,421,1454994000"; d="scan'208";a="168122091" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Mar 2016 06:23:08 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 31 Mar 2016 06:23:07 -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.0174.001; Thu, 31 Mar 2016 06:23:06 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Remote Participation for IETF 95: Meetecho Details Thread-Index: AdGLN0+2X7SrA1nWQgeJoZImZ+u58g== Date: Thu, 31 Mar 2016 10:23:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA751A9621@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.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: Remote Participation for IETF 95: Meetecho Details X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 10:23:16 -0000 SGksDQoNCkltcG9ydGFudCBpbmZvcm1hdGlvbiBmb3IgdGhlIHBhcnRpY2lwYW50cyB3aG8gcGxh biB0byBhdHRlbmQgcmVtb3RlbHkgdGhpcyBXRyBhbmQgb3RoZXIgc2Vzc2lvbnMgYXQgSUVURiA5 NS4gDQoNClJlZ2FyZHMsDQoNCkRhbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogSUVURi1Bbm5vdW5jZSBbbWFpbHRvOmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mDQo+IElFVEYgU2VjcmV0YXJpYXQNCj4gU2VudDogV2VkbmVzZGF5 LCBNYXJjaCAzMCwgMjAxNiAxMToyMyBQTQ0KPiBUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlzdA0K PiBDYzogd2djaGFpcnNAaWV0Zi5vcmc7IHJlY2VudGF0dGVuZGVlc0BpZXRmLm9yZzsgOTVhbGxA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmVtb3RlIFBhcnRpY2lwYXRpb24gZm9yIElFVEYgOTU6IE1l ZXRlY2hvIERldGFpbHMNCj4gDQo+IFlvdSBtYXkgdXNlIE1lZXRlY2hvIHRvIHBhcnRpY2lwYXRl IGluIG9yIGp1c3Qgb2JzZXJ2ZSBhbnkgc2Vzc2lvbiBiZWluZw0KPiBoZWxkIGluIEJ1ZW5vcyBB aXJlcy4gSGVyZSBhcmUgdGhlIHJlcXVpcmVtZW50cyBhbmQgZGV0YWlscy4NCj4gDQo+IDEuIElu ZGl2aWR1YWxzIGFyZSByZXF1aXJlZCB0byByZWdpc3RlciBmb3IgdGhlIG1lZXRpbmcgdG8gb2Jz ZXJ2ZSBvcg0KPiBwYXJ0aWNpcGF0ZSB2aWEgTWVldGVjaG8uDQo+IC0gSW5kaXZpZHVhbHMgYXJl IHJlcXVpcmVkIHRvIGVudGVyIHJlZ2lzdHJhdGlvbiBJLkQgYW5kIG5hbWUgd2hlbiBsb2dnaW5n DQo+IGludG8gYSBzZXNzaW9uIHZpYSBNZWV0ZWNobw0KPiAtIFRoZSBuYW1lIG11c3QgbWF0Y2gg dGhhdCB1c2VkIHRvIHJlZ2lzdGVyIGZvciB0aGUgbWVldGluZw0KPiAtIFBsZWFzZSByZWdpc3Rl ciBldmVuIGlmIHlvdSBhcmUgcGFydGljaXBhdGluZyBhcyBwYXJ0IG9mIHJlbW90ZSBodWINCj4g LSBUaGVyZSBpcyBubyBjb3N0IHRvIHJlZ2lzdGVyIGFzIGEgcmVtb3RlIGF0dGVuZGVlLiBSZWdp c3Rlcg0KPiBoZXJlOiBodHRwOi8vaWV0Zi5vcmcvbWVldGluZy9yZWdpc3Rlci5odG1sIA0KPiAN Cj4gMi4gUGFydGljaXBhdGlvbiBpbmNsdWRlcyB0aGUgYWJpbGl0eSB0byB0cmFuc21pdCBhdWRp byBhbmQgdmlkZW8gdmlhIHRoZQ0KPiBNZWV0ZWNobyB2aXJ0dWFsIHF1ZXVlLg0KPiAtIFRoZSB2 aXJ0dWFsIHF1ZXVlIHBlcm1pdHMgcmVtb3RlIGF0dGVuZGVlcyB0byBzaGFyZSBhdWRpbyBhbmQg dmlkZW8gaWYNCj4gdGhleSBjaG9vc2UsIHNlZSBoZXJlIGZvciBtb3JlIGluZm9ybWF0aW9uOg0K PiBodHRwczovL2lldGY5NS5jb25mLm1lZXRlY2hvLmNvbS9pbmRleC5waHAvVU1QSVJFX1Byb2pl Y3QNCj4NCj4gLSBBbnlvbmUgd2hvIHRoaW5rcyB0aGV5IG1heSB3YW50IHRvIHBhcnRpY2lwYXRl IGJ5IHRyYW5zbWl0dGluZyBhdWRpbyAvDQo+IHZpZGVvIHNob3VsZCBwZXJmb3JtIHRoZSBNZWV0 ZWNobyBzZWxmLXRlc3QgcHJpb3IgdG8gdGhlIHN0YXJ0IG9mIHRoZQ0KPiBzZXNzaW9uOiBodHRw Oi8vaWV0Zjk1LmNvbmYubWVldGVjaG8uY29tL2luZGV4LnBocC9TZWxmX1Rlc3QNCj4gDQo+IDMu IFdHIENoYWlycyB3aWxsIGNvbnRyb2wgdGhlIHZpcnR1YWwgcXVldWUsIHVubXV0aW5nIGFuZCBt dXRpbmcgb2YgcmVtb3RlDQo+IHBhcnRpY2lwYW50cw0KPiANCj4gNC4gVGhlIGFnZW5kYSBmb3Ig dGhlIFdHIHNlc3Npb25zLCBhcyB3ZWxsIGFzIG1vcmUgZGV0YWlsIG9uIGhvdyB0byB1c2UNCj4g TWVldGVjaG8gdG8gcGFydGljaXBhdGUsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2ll dGY5NS5jb25mLm1lZXRlY2hvLmNvbS9pbmRleC5waHAvDQoNCg0K From nobody Thu Mar 31 17:53:22 2016 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 4BACD12D51D for ; Thu, 31 Mar 2016 17:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viavisolutions-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEGSiqCxgX-t for ; Thu, 31 Mar 2016 17:53:19 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3279812D508 for ; Thu, 31 Mar 2016 17:53:19 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id p65so5726005wmp.1 for ; Thu, 31 Mar 2016 17:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viavisolutions-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:cc; bh=6ufVfOtB+xKRFqYKhfJ2JJ2YSIDAKL4EMrqsJhDvwoE=; b=rG48uXu/4Q40VYo+1jLd+PLDZmYndRjuSMZggmSSlEOm/MJRdJ/nX1tQXYWyv+flOh 1pRHGOot4K/XJLONP2Bn6eGp/8nxhlzcKypWByincpO/vl1uUioJmgOfyca2PlBktoWZ uIKHsqM+aDNE+GwjP61xfKsOGtXAZzQG7a9fWeuAZo7wXCM9JcLFNpAn2RFonKNe21fs MZsdNfDDA37JS7cLnbXJwF/3wilY0Fc7d3D4RfBsooiYyPvEgsMqheFqleJhjpdb1cMS waDgnTWoX5P3iqBLYt0ntFmxL+sZ+BHTMTOFdvnCP3PaGAEEX32qQNJWWYNnbTSMGl8/ ZV4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=6ufVfOtB+xKRFqYKhfJ2JJ2YSIDAKL4EMrqsJhDvwoE=; b=UJSQtwLZZYnj5gXRFC4ZdFiqqilt2PihNtVVDziYg9dvFYRCWBiSPCSqhhTFYmKSwn jfUzOQAE2rT9/a2VkB5l7mbMUB+UBJZUYx8WHuTxq6f7FlvR9Ynn8K6eeXD6PjE8zPfK b5X6+yubdCOWtp52tQquvCPOUUAqwe03khGbgUHYOpJdYzegbx1ABc8MZTm+bwtCUgZr nL5oX1w+tfaDRXtcmvwIdmnAQOJ+Y0pDoqrMa1v4cevRwpBBhiuYVomodd1V6ApUXulL UZ7aEKD3BTmjMjQMBmN6jjZ1RiDj3Ci8c/lH3tzEDVE+fWbAdFkyF7WHY+j+80aac+oH inSw== X-Gm-Message-State: AD7BkJIwCa9T+1SzSjlNngn6Vxt0Q8LzhkM0NgLorbuMbc5ffS1eM+1DGkidAsiaVh7ip4yMXLCfGJ4GIKT523Dk MIME-Version: 1.0 X-Received: by 10.28.234.151 with SMTP id g23mr557094wmi.40.1459471997576; Thu, 31 Mar 2016 17:53:17 -0700 (PDT) Received: by 10.28.127.65 with HTTP; Thu, 31 Mar 2016 17:53:17 -0700 (PDT) Date: Thu, 31 Mar 2016 20:53:17 -0400 Message-ID: From: Ron Stana To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a11476894f9ca25052f61cdb4 Archived-At: Cc: alissa@cooperw.in Subject: [lmap] Learning MA Capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 00:53:21 -0000 --001a11476894f9ca25052f61cdb4 Content-Type: text/plain; charset=UTF-8 LMAP Team, We want the MA to provide information to the Controller that will be used to characterize/limit the Measurement Tasks that are later executed. Examples include: - licenses for optional features - max test bandwidth - total number of simultaneous tests and data streams (based on VM resources for virtual devices) This appears to be information that LMAP suggests can be provided as part of getting the capabilities from the MA. I have two questions based on version 9 of the LMAP Information Model. 1) Which API should be used to pass this information from the MA to the Controller? - ietf-lmap-control:lmap-state seems logical however there doesn't appear to be a place for this type of information in it - One possibility is to define a 'capability task' whose ietf-lmap-control:lmap/tasks/task/option contains the data. The controller could then GET the ietf-lmap-control:lmap object to the values. However, I am not sure if tasks were envisioned to return data in this manner. 2) While looking into how to solve this issue we found https://tools.ietf.org/html/rfc7223. Has any consideration been given to adding the 'interfaces' or 'interfaces-state' objects defined in that document to ietf-lmap-control/lmap-state? This would partially address the issue above but more importantly being able to get general RX and TX statistics on the test interface would be useful for general MA troubleshooting. Regards, Ron --001a11476894f9ca25052f61cdb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
LMAP Team,

We want the MA to provide in= formation to the Controller that will be used to characterize/limit the Mea= surement Tasks that are later executed. =C2=A0

Exa= mples include:
  • licenses for optional features
  • max= test bandwidth
  • total number of simultaneous tests and data streams= (based on VM resources for virtual devices)=C2=A0
This appea= rs to be information that LMAP suggests can be provided as part of getting = the capabilities from the MA.=C2=A0 I have two questions based on version 9= of the LMAP Information Model.

1) Which API= should be used to pass this information from the MA to the Controller? =C2= =A0
  • ietf-lmap-control:lmap-state seems logical however th= ere doesn't appear to be a place for this type of information in it
    =
  • One possibility is to define a 'capability task' whose iet= f-lmap-control:lmap/tasks/task/option contains the data.=C2=A0 The controll= er could then GET the=C2=A0ietf-lmap-control:lmap object to the values.=C2= =A0 However, I am not sure if tasks were envisioned to return data in this = manner.
2) While looking into how to solve this issue we foun= d https://tools.ietf.org/ht= ml/rfc7223.=C2=A0 Has any consideration been given to adding the 'i= nterfaces' or 'interfaces-state' objects defined in that docume= nt to ietf-lmap-control/lmap-state?=C2=A0 This would partially address the = issue above but more importantly being able to get general RX and TX statis= tics on the test interface would be useful for general MA troubleshooting.<= /div>

Regards,
Ron
--001a11476894f9ca25052f61cdb4-- From nobody Thu Mar 31 18:19:13 2016 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 C484112D5E2 for ; Thu, 31 Mar 2016 18:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viavisolutions-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FPNJct2za4X for ; Thu, 31 Mar 2016 18:19:09 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCA912D1A1 for ; Thu, 31 Mar 2016 18:19:09 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f198so6257154wme.0 for ; Thu, 31 Mar 2016 18:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viavisolutions-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=yQi5j2KmZFib5uRNcYGEemChsUzHAnTCtd9+WK1RB8Y=; b=UN9BpQidIpPOC02KObypcSc52CGRYycG1gJ6I+72csXXDQeMDdstD++H9CNkSZyTci YhdeAiPSpG9ovkAnMzGNe5OvSnWpF2WiTE6hyZhtjV/bLM3T8cuE0PexEKUpI0rMDEk2 h/y8ivJJeqWtR75aRsxb4ZzAtgAq+ex7NQZXFxm/OS8TjknaAxcUjgVItu0VYB2j/1v5 vhAxon6zujApyvxk8rbwLchGc16V3jQQnxahogZrBAP3YWbluVO4VwLqHWlwiXCPeX9X pLMx1CCajE3aLqLdvffVsjqBmOwH7XPim8PoSyr/5t9P/3YTRj1P+NLI4c1Y9HZDIEW+ phDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=yQi5j2KmZFib5uRNcYGEemChsUzHAnTCtd9+WK1RB8Y=; b=DBLCp8rzvu6mqU7GLQqXnI4UmIlHG/Nnx3mM197xFBkE6tvu0+bE3LrOTfiNFL/V5B hVxoBeC2Xxxa27xv8lwPOd3DE8EKuCfk6TPG7b/th3dL/jbDnjFAzxLbSkf+No4NiuBy rLzsl6lZbPQ4vQ77QCQET6v609xs9xl6y/+KgC3/Ywns8LHeMsMj7Lzq7lt/Aaj7TiQR yDFxtITSuzIVJvLeyFDgGWWw7L6c7mlQWViuMjlM9BgLP9g4BvW/zG7xAobdCdK7hras sCRkmgw8nc8JBLjB31/1gEo2puzojsnP2vWNa7v7xu9zxkkgUa3HleA1ytoC09CAoWZj ZCig== X-Gm-Message-State: AD7BkJIx/aarjDoIPUexl0tysZtV3sfcXaf5E48Yje8egG59/ddl8o/oXA0vH77DeQSgIW9sEkzD/9ZV5uB+C4by MIME-Version: 1.0 X-Received: by 10.194.123.131 with SMTP id ma3mr6122094wjb.107.1459473547591; Thu, 31 Mar 2016 18:19:07 -0700 (PDT) Received: by 10.28.127.65 with HTTP; Thu, 31 Mar 2016 18:19:07 -0700 (PDT) In-Reply-To: <20160222085611.GA12467@elstar.local> References: <9966516C6EB5FC4381E05BF80AA55F77012A5CE3C2@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A5D0DBB@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160222085611.GA12467@elstar.local> Date: Thu, 31 Mar 2016 21:19:07 -0400 Message-ID: From: Ron Stana To: Juergen Schoenwaelder , Ron Stana , "Carey, Timothy (Nokia - US)" , "alissa@cooperw.in" , "lmap@ietf.org" Content-Type: multipart/alternative; boundary=089e012287f05d2bcd052f622a4b Archived-At: Subject: Re: [lmap] Support for multiple report table formats from one task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 01:19:13 -0000 --089e012287f05d2bcd052f622a4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Juergen, The changes to version 4 of the LMAP YANG model ( https://tools.ietf.org/html/draft-ietf-lmap-yang-04) allow for multiple tables to be sent for one task, so thank you. However the client application will need to be able to determine what data is in each of the different tables. There were two suggestions made in this thread: 1) use different registry references for each table via the metric object 2) use different values in the 'tag' object for each table The problem I see is neither the 'metric' or 'tag' objects are within the new 'table' object so each table cannot define its own value for these. Regards, Ron On Mon, Feb 22, 2016 at 3:56 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Ron, > > the YANG data model already has a tag to distinguish multiple > 'tables'. But even with that tag in place, I think the reporting model > is not working well yet. I agree that there is room for improvement. > > One of the odd things is also that results are produced by actions, > not by claim to report by tasks. This alone causes trouble because > actions may use options that impact the result format. Originally, we > did not have the notion of actions and somehow the result model simply > lags behind. > > I need to think more about how to do this properly. I do not have a > solution proposal yet but I agree that the reporting model needs some > more work (once we have the configuration/instruction model stable). > > /js > > On Tue, Feb 16, 2016 at 09:46:23AM -0500, Ron Stana wrote: > > Tim, > > > > I am trying to determine how one task can produce results that require > > multiple table formats (what I called report types) and send them to th= e > > collector at the same time. Most tasks we have will require this type = of > > functionality. > > > > This is my understanding of what we have discussed so far: > > 1) The registry would be used to define the different table formats...f= or > > the purpose of this discussion let's go with your suggestion that there > > would be one entry for each table format. > > 2) The multiple registry entries are then assigned to a single task usi= ng > > multiple instances of the the lmap/tasks/task/metric object. > > 3) When the task goes to send these different tables of results to the > > Collector, it identifies the table that is being sent using a single > > instance of the the report/task/metric object. > > > > If we agree thus far then the part that remains is how to send multiple > > tables to the collector at one time. The current report model only > allows > > each task to have one entry so the MA would have to POST a separate > report > > for each table. I am asking if the tables could all be sent together. > > > > Ron > > > > On Tue, Feb 16, 2016 at 1:14 AM, Carey, Timothy (Nokia - US) < > > timothy.carey@nokia.com> wrote: > > > > > Ron, > > > > > > > > > > > > I was thinking about this some more last night. > > > > > > > > > > > > Are you asking to categorize the reports by registry entry? - which I > > > think you call report type? If so I don=E2=80=99t see an issue with = that =E2=80=93 we > can > > > use the registry entry as part of the report results=E2=80=A6 > > > > > > > > > > > > BR, > > > > > > Tim > > > > > > > > > > > > *From:* Carey, Timothy (Nokia - US) > > > *Sent:* Monday, February 15, 2016 10:31 PM > > > *To:* 'Ron Stana' > > > *Cc:* alissa@cooperw.in; lmap@ietf.org > > > *Subject:* RE: [lmap] Support for multiple report table formats from > one > > > task > > > > > > > > > > > > Ron, > > > > > > > > > > > > I would talk to the IPPM team then =E2=80=93 its really how they defi= ne the > > > metrics that make up the registry. > > > > > > > > > > > > As for a report per task constraint =E2=80=93 I don=E2=80=99t know if= saving inputs and > > > outputs as you suggest warrant breaking that constraint =E2=80=93 why= not just > have > > > 2 tasks and duplicate the registry entry. > > > > > > > > > > > > I like the when the task is complete =E2=80=93 generate the results f= or > reporting > > > and then report results based on the schedule to the collector. I kno= w > in > > > our BBF implementation this works quite well. > > > > > > > > > > > > Otherwise you get into the nasty problem of a state machine that > > > correlates running the tests with reporting results in the context of > the > > > overarching scheduled task (You call it running and final but there i= s > a > > > context to those states for that particular task). > > > > > > > > > > > > BR, > > > > > > Tim > > > > > > > > > > > > > > > > > > *From:* Ron Stana [mailto:ron.stana@viavisolutions.com > > > ] > > > *Sent:* Monday, February 15, 2016 5:40 PM > > > *To:* Carey, Timothy (Nokia - US) > > > *Cc:* alissa@cooperw.in; lmap@ietf.org > > > *Subject:* Re: [lmap] Support for multiple report table formats from > one > > > task > > > > > > > > > > > > Tim, > > > > > > > > > > > > While multiple registry entries could be used to define each of the > report > > > types (table formats), this would require those registry entries to > > > replicate the inputs ('fixed parameters' in registry terms) and any > outputs > > > that are common across the different types. It would be better to > have one > > > registry entry that defined the inputs to the task once, all possible > > > outputs once and then allowed the outputs to be grouped into differen= t > > > report types. The report type is just some string value. When the > tables > > > were sent from the MA to the Collector they would then just need to > include > > > the report type. > > > > > > > > > > > > Example: > > > > > > 1) Task measures bandwidth for one or more streams > > > > > > 2) One registry entry is defined for the task. It includes: > > > > > > a) the numerous inputs that define the stream's packet format > > > > > > b) an output definition for the 'last one second bandwidth' > > > > > > c) an output definition for the 'average bandwidth since task > start' > > > > > > 3) The 'last one second bandwidth' is only useful while the task is > > > running so it is assigned to the report type 'running'. The > description of > > > the output > > > > > > 4) The 'average bandwidth since task start' is useful while the task = is > > > running and as a final value when the task completes so it is assigne= d > to > > > the report types 'running' and 'final'. > > > > > > 5) When the reports are sent from the MA, they indicate the report > type. > > > This is where I suggested the 'tag' object in the report could be use= d. > > > > > > > > > > > > In the end I am asking about these three issues: > > > > > > 1) How does a task properly define multiple report types (tables)? > > > > > > 2) How does the MA identify the report type being sent? > > > > > > Even if #1 is addressed using multiple registry entries, and #2 is > > > addressed by including a reference to the registry entry in the > > > 'metric/uri' object of the task within the report, there is still thi= s > > > issue: > > > > > > 3) How does the MA send multiple report types at the same time? My > > > understanding of the current report definition is that it limits each > task > > > to having one table definition per POST. The MA could send each tabl= e > > > definition to the collector separately but allowing each task to send > an > > > array of table definitions would be more efficient. > > > > > > > > > > > > You brought up a fourth issue which is how the data in each table is > > > mapped to the registry. I have been making the assumption this was > going > > > to be accomplished by setting the column header value in the report t= o > one > > > of the summary/name values defined in the registry for the metric. > > > > > > > > > > > > Ron > > > > > > > > > > > > On Sun, Feb 14, 2016 at 11:11 AM, Carey, Timothy (Nokia - US) < > > > timothy.carey@nokia.com> wrote: > > > > > > Ron, > > > > > > > > > > > > The task has multiple registry entries =E2=80=93 I would assume your = example is > > > that this task > > > > > > would have 3 registry entries. > > > > > > > > > > > > The columns are for the task and would have to have a union of all th= e > > > metrics for registry entries. =E2=80=93 Is this what you were asking? > > > > > > > > > > > > It seems that we lose the context of the registry entry to column > though=E2=80=A6 > > > > > > > > > > > > BR, > > > > > > Tim > > > > > > > > > > > > *From:* Ron Stana [mailto:ron.stana@viavisolutions.com] > > > *Sent:* Friday, February 12, 2016 4:31 PM > > > *To:* lmap@ietf.org > > > *Cc:* alissa@cooperw.in > > > *Subject:* [lmap] Support for multiple report table formats from one > task > > > > > > > > > > > > LMAP Team, > > > > > > > > > > > > My understanding of the LMAP proposal is > ietf-lmap-report:report/task/name > > > is supposed to contain one of the values defined in > > > ietf-lmap-control:lmap/tasks/task/name. > > > > > > > > > > > > If this is correct, and since each task instance within a report can > only > > > contain one table definition (one header + its row data) then how doe= s > a > > > task send multiple tables of results that contain different table > formats? > > > > > > > > > > > > Use Cases: > > > > > > 1) Y.1564 task has results for the Service Configuration and the > Service > > > Performance data, and each table has a different set of columns. > > > > > > 2) An RFC-2544 task would need a different table for the Throughput, > > > Latency, Frame Loss and Back to Back result sets. > > > > > > 3) Any task may want to send a minimal result set while it is executi= ng > > > that is very different from the final result set when it has complete= d. > > > > > > > > > > > > The ietf-lmap-report:report/task/tag could be used to differentiate t= he > > > result sets sent by the same task. However this is not very efficient > since > > > this approach requires the MA to send each report to the collector > > > separately because each report can only contain one set of results pe= r > task > > > name. > > > > > > > > > > > > Any guidance or clarification on the LMAP proposal would be > appreciated, > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 > --089e012287f05d2bcd052f622a4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

The changes to version 4 of th= e LMAP YANG model (htt= ps://tools.ietf.org/html/draft-ietf-lmap-yang-04) allow for multiple ta= bles to be sent for one task, so thank you.=C2=A0 However the client applic= ation will need to be able to determine what data is in each of the differe= nt tables.=C2=A0 There were two suggestions made in this thread:
=
1) use different registry references for each table via the = metric object
2) use different values in the 'tag' object= for each table

The problem I see is neither the &= #39;metric' or 'tag' objects are within the new 'table'= object so each table cannot define its own value for these.

=
Regards,
Ron


On Mon, Feb 22, 2016 at 3:56 AM,= Juergen Schoenwaelder <j.schoenwaelder@jacobs-universi= ty.de> wrote:
Ron,

the YANG data model already has a tag to distinguish multiple
'tables'. But even with that tag in place, I think the reporting mo= del
is not working well yet. I agree that there is room for improvement.

One of the odd things is also that results are produced by actions,
not by claim to report by tasks. This alone causes trouble because
actions may use options that impact the result format. Originally, we
did not have the notion of actions and somehow the result model simply
lags behind.

I need to think more about how to do this properly. I do not have a
solution proposal yet but I agree that the reporting model needs some
more work (once we have the configuration/instruction model stable).

/js

On Tue, Feb 16, 2016 at 09:46:23AM -0500, Ron Stana wrote:
> Tim,
>
> I am trying to determine how one task can produce results that require=
> multiple table formats (what I called report types) and send them to t= he
> collector at the same time.=C2=A0 Most tasks we have will require this= type of
> functionality.
>
> This is my understanding of what we have discussed so far:
> 1) The registry would be used to define the different table formats...= for
> the purpose of this discussion let's go with your suggestion that = there
> would be one entry for each table format.
> 2) The multiple registry entries are then assigned to a single task us= ing
> multiple instances of the the lmap/tasks/task/metric object.
> 3) When the task goes to send these different tables of results to the=
> Collector, it identifies the table that is being sent using a single > instance of the the report/task/metric object.
>
> If we agree thus far then the part that remains is how to send multipl= e
> tables to the collector at one time.=C2=A0 The current report model on= ly allows
> each task to have one entry so the MA would have to POST a separate re= port
> for each table.=C2=A0 I am asking if the tables could all be sent toge= ther.
>
> Ron
>
> On Tue, Feb 16, 2016 at 1:14 AM, Carey, Timothy (Nokia - US) <
> timothy.carey@nokia.com= > wrote:
>
> > Ron,
> >
> >
> >
> > I was thinking about this some more last night.
> >
> >
> >
> > Are you asking to categorize the reports by registry entry? - whi= ch I
> > think you call report type?=C2=A0 If so I don=E2=80=99t see an is= sue with that =E2=80=93 we can
> > use the registry entry as part of the report results=E2=80=A6
> >
> >
> >
> > BR,
> >
> > Tim
> >
> >
> >
> > *From:* Carey, Timothy (Nokia - US)
> > *Sent:* Monday, February 15, 2016 10:31 PM
> > *To:* 'Ron Stana'
> > *Cc:* alissa@cooperw.in;= lmap@ietf.org
> > *Subject:* RE: [lmap] Support for multiple report table formats f= rom one
> > task
> >
> >
> >
> > Ron,
> >
> >
> >
> > I would talk to the IPPM team then =E2=80=93 its really how they = define the
> > metrics that make up the registry.
> >
> >
> >
> > As for a report per task constraint =E2=80=93 I don=E2=80=99t kno= w if saving inputs and
> > outputs as you suggest warrant breaking that constraint =E2=80=93= why not just have
> > 2 tasks and duplicate the registry entry.
> >
> >
> >
> > I like the when the task is complete =E2=80=93 generate the resul= ts for reporting
> > and then report results based on the schedule to the collector. I= know in
> > our BBF implementation this works quite well.
> >
> >
> >
> > Otherwise you get into the nasty problem of a state machine that<= br> > > correlates running the tests with reporting results in the contex= t of the
> > overarching scheduled task (You call it running and final but the= re is a
> > context to those states for that particular task).
> >
> >
> >
> > BR,
> >
> > Tim
> >
> >
> >
> >
> >
> > *From:* Ron Stana [mailto:ron.stana@viavisolutions.com
> > <ron.stana@via= visolutions.com>]
> > *Sent:* Monday, February 15, 2016 5:40 PM
> > *To:* Carey, Timothy (Nokia - US)
> > *Cc:* alissa@cooperw.in;= lmap@ietf.org
> > *Subject:* Re: [lmap] Support for multiple report table formats f= rom one
> > task
> >
> >
> >
> > Tim,
> >
> >
> >
> > While multiple registry entries could be used to define each of t= he report
> > types (table formats), this would require those registry entries = to
> > replicate the inputs ('fixed parameters' in registry term= s) and any outputs
> > that are common across the different types.=C2=A0 It would be bet= ter to have one
> > registry entry that defined the inputs to the task once, all poss= ible
> > outputs once and then allowed the outputs to be grouped into diff= erent
> > report types. The report type is just some string value. When the= tables
> > were sent from the MA to the Collector they would then just need = to include
> > the report type.
> >
> >
> >
> > Example:
> >
> > 1) Task measures bandwidth for one or more streams
> >
> > 2) One registry entry is defined for the task. It includes:
> >
> >=C2=A0 =C2=A0 =C2=A0a) the numerous inputs that define the stream&= #39;s packet format
> >
> >=C2=A0 =C2=A0 =C2=A0b) an output definition for the 'last one = second bandwidth'
> >
> >=C2=A0 =C2=A0 =C2=A0c) an output definition for the 'average b= andwidth since task start'
> >
> > 3) The 'last one second bandwidth' is only useful while t= he task is
> > running so it is assigned to the report type 'running'.= =C2=A0 The description of
> > the output
> >
> > 4) The 'average bandwidth since task start' is useful whi= le the task is
> > running and as a final value when the task completes so it is ass= igned to
> > the report types 'running' and 'final'.
> >
> > 5) When the reports are sent from the MA, they indicate the repor= t type.
> > This is where I suggested the 'tag' object in the report = could be used.
> >
> >
> >
> > In the end I am asking about these three issues:
> >
> > 1) How does a task properly define multiple report types (tables)= ?
> >
> > 2) How does the MA identify the report type being sent?
> >
> > Even if #1 is addressed using multiple registry entries, and #2 i= s
> > addressed by including a reference to the registry entry in the > > 'metric/uri' object of the task within the report, there = is still this
> > issue:
> >
> > 3) How does the MA send multiple report types at the same time? M= y
> > understanding of the current report definition is that it limits = each task
> > to having one table definition per POST.=C2=A0 The MA could send = each table
> > definition to the collector separately but allowing each task to = send an
> > array of table definitions would be more efficient.
> >
> >
> >
> > You brought up a fourth issue which is how the data in each table= is
> > mapped to the registry.=C2=A0 I have been making the assumption t= his was going
> > to be accomplished by setting the column header value in the repo= rt to one
> > of the summary/name values defined in the registry for the metric= .
> >
> >
> >
> > Ron
> >
> >
> >
> > On Sun, Feb 14, 2016 at 11:11 AM, Carey, Timothy (Nokia - US) <= ;
> > timothy.carey@nokia.co= m> wrote:
> >
> > Ron,
> >
> >
> >
> > The task has multiple registry entries =E2=80=93 I would assume y= our example is
> > that this task
> >
> > would have 3 registry entries.
> >
> >
> >
> > The columns are for the task and would have to have a union of al= l the
> > metrics for registry entries. =E2=80=93 Is this what you were ask= ing?
> >
> >
> >
> > It seems that we lose the context of the registry entry to column= though=E2=80=A6
> >
> >
> >
> > BR,
> >
> > Tim
> >
> >
> >
> > *From:* Ron Stana [mailto:ron.stana@viavisolutions.com]
> > *Sent:* Friday, February 12, 2016 4:31 PM
> > *To:* lmap@ietf.org
> > *Cc:* alissa@cooperw.in<= br> > > *Subject:* [lmap] Support for multiple report table formats from = one task
> >
> >
> >
> > LMAP Team,
> >
> >
> >
> > My understanding of the LMAP proposal is ietf-lmap-report:report/= task/name
> > is supposed to contain one of the values defined in
> > ietf-lmap-control:lmap/tasks/task/name.
> >
> >
> >
> > If this is correct, and since each task instance within a report = can only
> > contain one table definition (one header + its row data) then how= does a
> > task send multiple tables of results that contain different table= formats?
> >
> >
> >
> > Use Cases:
> >
> > 1) Y.1564 task has results for the Service Configuration and the = Service
> > Performance data, and each table has a different set of columns.<= br> > >
> > 2) An RFC-2544 task would need a different table for the Throughp= ut,
> > Latency, Frame Loss and Back to Back result sets.
> >
> > 3) Any task may want to send a minimal result set while it is exe= cuting
> > that is very different from the final result set when it has comp= leted.
> >
> >
> >
> > The ietf-lmap-report:report/task/tag could be used to differentia= te the
> > result sets sent by the same task. However this is not very effic= ient since
> > this approach requires the MA to send each report to the collecto= r
> > separately because each report can only contain one set of result= s per task
> > name.
> >
> >
> >
> > Any guidance or clarification on the LMAP proposal would be appre= ciated,
> >
> >
> >
> > Ron
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

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


--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

--089e012287f05d2bcd052f622a4b--