From nobody Tue Jan 5 04:42:33 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 9AFCE1B2D24 for ; Tue, 5 Jan 2016 04:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 N5zk01XN1cu4 for ; Tue, 5 Jan 2016 04:42:30 -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 1D0001B2D52 for ; Tue, 5 Jan 2016 04:42:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AeAwBBP8ZV/yYyC4dbGQSCMSEsVG+pbgaTNgmHfQKBJjgUAQEBAQEBAX8LhCUBAQMSG14BDAkVViYBBBsaiAwBp22FC6A+DAEfhh+JaQEBH4NQgRQFkgWDBgGOK4QlgwuRBBcPg32BfTqBBAEBAQ X-IPAS-Result: A2AeAwBBP8ZV/yYyC4dbGQSCMSEsVG+pbgaTNgmHfQKBJjgUAQEBAQEBAX8LhCUBAQMSG14BDAkVViYBBBsaiAwBp22FC6A+DAEfhh+JaQEBH4NQgRQFkgWDBgGOK4QlgwuRBBcPg32BfTqBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208,217";a="137362860" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Jan 2016 07:42:28 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 05 Jan 2016 07:42:27 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 5 Jan 2016 13:42:25 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP virtual interim - one week from now! Thread-Index: AdFHtocHN8pg0ocGSEi9sRBN/8p0HA== Date: Tue, 5 Jan 2016 12:42:24 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEDD468@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_9904FB1B0159DA42B0B887B7FA8119CA6BEDD468AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP virtual interim - one week from now! 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: Tue, 05 Jan 2016 12:42:32 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEDD468AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Happy New Year! The LMAP virtual interim is scheduled for Tuesday 1/12, at 1PM EST. The level of activity since IETF 95 is close to zero. No I-Ds were submitte= d since Yokohama, and no discussions were recorded on the mail list. This d= oes not look good. Document editors - please let us know whether you plan to submit updates be= fore the meeting date next week. All - please comment whether we should hold the meeting or re-schedule. If = you favor holding the meeting, please let us know what you believe should b= e on the agenda. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEDD468AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Happy New Year!

 

The LMAP virtual interim is scheduled for Tuesday 1/= 12, at 1PM EST.

 

The level of activity since IETF 95 is close to zero= . No I-Ds were submitted since Yokohama, and no discussions were recorded o= n the mail list. This does not look good.

 

Document editors – please let us know whether = you plan to submit updates before the meeting date next week.

 

All – please comment whether we should hold th= e meeting or re-schedule. If you favor holding the meeting, please let us k= now what you believe should be on the agenda.

 

Thanks and Regards,

 

Dan

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BEDD468AZFFEXMB04globa_-- From nobody Wed Jan 6 03:19:31 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 969721ACEC2 for ; Wed, 6 Jan 2016 03:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 yg7sVpJBhPoY for ; Wed, 6 Jan 2016 03:19:29 -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 D00561A9171 for ; Wed, 6 Jan 2016 03:19:28 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8C1A4FA6; Wed, 6 Jan 2016 12:19:27 +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 CBb0zg7n8t4n; Wed, 6 Jan 2016 12:19:26 +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; Wed, 6 Jan 2016 12:19:26 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3641C20056; Wed, 6 Jan 2016 12:19:26 +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 g1Rvq4RHwPDN; Wed, 6 Jan 2016 12:19:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 329E920055; Wed, 6 Jan 2016 12:19:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2C362397CC1D; Wed, 6 Jan 2016 12:19:22 +0100 (CET) Date: Wed, 6 Jan 2016 12:19:22 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160106111920.GA25743@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA6BEDD468@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BEDD468@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP virtual interim - one week from now! 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: Wed, 06 Jan 2016 11:19:30 -0000 Dan, I had a short chat with Al Morton yesterday. He has updated the IPPM initial metric registry content I-D recently: https://tools.ietf.org/html/draft-morton-ippm-initial-registry-03 One of the open issues we have is how the registry relates to the LMAP info/data model. I meanwhile consider the registry at the conceptual information model level and I am exploring the idea to translate the 'Run-time Parameters and Data Format' and 'Output' formats into YANG definitions that hook into the data model. I am trying to explore this further until Tuesday (trying to translate some of the examples in the above I-D) and this might be worth to discuss on Tuesday. That said, I won't have updated LMAP WG I-Ds by Tuesday. I suggest to have the virtual meeting even if we might be done early instead of postponing (since re-scheduling is associated with quite some administrative effort). /js On Tue, Jan 05, 2016 at 12:42:24PM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > Happy New Year! > > The LMAP virtual interim is scheduled for Tuesday 1/12, at 1PM EST. > > The level of activity since IETF 95 is close to zero. No I-Ds were submitted since Yokohama, and no discussions were recorded on the mail list. This does not look good. > > Document editors - please let us know whether you plan to submit updates before the meeting date next week. > > All - please comment whether we should hold the meeting or re-schedule. If you favor holding the meeting, please let us know what you believe should be on the agenda. > > Thanks and Regards, > > Dan > _______________________________________________ > 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 Wed Jan 6 05:15: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 4E15B1B2B6F for ; Wed, 6 Jan 2016 05:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mwQ0xWKTLy4u for ; Wed, 6 Jan 2016 05:14:56 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7FA1B2B68 for ; Wed, 6 Jan 2016 05:14:56 -0800 (PST) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id A2D62122524; Wed, 6 Jan 2016 08:16:15 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-azure.research.att.com (Postfix) with ESMTP id B8B8BE051A; Wed, 6 Jan 2016 08:14:52 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 6 Jan 2016 08:14:52 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "Romascanu, Dan (Dan)" Date: Wed, 6 Jan 2016 08:14:51 -0500 Thread-Topic: [lmap] LMAP virtual interim - one week from now! Thread-Index: AdFIdCWXT01GKP1sR8+1/2oFLtKhkAACpldQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D1D9E9E47F7@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BEDD468@AZ-FFEXMB04.global.avaya.com> <20160106111920.GA25743@elstar.local> In-Reply-To: <20160106111920.GA25743@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP virtual interim - one week from now! 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, 06 Jan 2016 13:14:59 -0000 +1, and adding that the registry contents draft has been=20 updated twice since IETF-94, so diff 01 - 03 to see the full changes. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, January 06, 2016 6:19 AM > To: Romascanu, Dan (Dan) > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP virtual interim - one week from now! >=20 > Dan, >=20 > I had a short chat with Al Morton yesterday. He has updated the IPPM > initial metric registry content I-D recently: >=20 > https://tools.ietf.org/html/draft-morton-ippm-initial-registry-03 >=20 > One of the open issues we have is how the registry relates to the LMAP > info/data model. I meanwhile consider the registry at the conceptual > information model level and I am exploring the idea to translate the > 'Run-time Parameters and Data Format' and 'Output' formats into YANG > definitions that hook into the data model. I am trying to explore this > further until Tuesday (trying to translate some of the examples in the > above I-D) and this might be worth to discuss on Tuesday. That said, I > won't have updated LMAP WG I-Ds by Tuesday. >=20 > I suggest to have the virtual meeting even if we might be done early > instead of postponing (since re-scheduling is associated with quite > some administrative effort). >=20 > /js >=20 > On Tue, Jan 05, 2016 at 12:42:24PM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > Happy New Year! > > > > The LMAP virtual interim is scheduled for Tuesday 1/12, at 1PM EST. > > > > The level of activity since IETF 95 is close to zero. No I-Ds were > submitted since Yokohama, and no discussions were recorded on the mail > list. This does not look good. > > > > Document editors - please let us know whether you plan to submit > updates before the meeting date next week. > > > > All - please comment whether we should hold the meeting or re- > schedule. If you favor holding the meeting, please let us know what you > believe should be on the agenda. > > > > Thanks and Regards, > > > > Dan >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Jan 7 05:33:35 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 DDED01A89B4 for ; Thu, 7 Jan 2016 05:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 TdULJJFsrsww for ; Thu, 7 Jan 2016 05:33:31 -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 1BCED1A89B0 for ; Thu, 7 Jan 2016 05:33:30 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CWAwBBP8ZV/xUHmMZbGQSCMSEsIzFpBqluBgWTMQmBWCIBC4V3AoEmOBQBAQEBAQEBfwuEJQEBAxIbRRkBFRULSyYBBBsBGYgMAQynYYULoD4BAQEHAQEBAR6GH4lpAQEfLRWCJAxBHYEUBZULAY4rhCWDC5EEFw+DfW8BgQ06gQQBAQE X-IPAS-Result: A2CWAwBBP8ZV/xUHmMZbGQSCMSEsIzFpBqluBgWTMQmBWCIBC4V3AoEmOBQBAQEBAQEBfwuEJQEBAxIbRRkBFRULSyYBBBsBGYgMAQynYYULoD4BAQEHAQEBAR6GH4lpAQEfLRWCJAxBHYEUBZULAY4rhCWDC5EEFw+DfW8BgQ06gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208,217";a="137679466" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Jan 2016 08:33:29 -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 Jan 2016 08:33:27 -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; Thu, 7 Jan 2016 14:33:26 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP Virtual Interim meeting on 1/12 - Draft Agenda Thread-Index: AdFJT/xNmGBNCDvQSiSteG9RPkECaQ== Date: Thu, 7 Jan 2016 13:33:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEE0724@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_9904FB1B0159DA42B0B887B7FA8119CA6BEE0724AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Agenda 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: Thu, 07 Jan 2016 13:33:34 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEE0724AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Taking into account the inputs from Al and Juergen, we shall proceed with h= olding the virtual interim meeting as planned, on Tuesday 1/12/16, at 1PM E= T. Meeting information: http://www.ietf.org/mail-archive/web/lmap/current/msg0= 2369.html The draft agenda is available at https://www.ietf.org/proceedings/interim/2= 016/01/12/lmap/agenda/agenda-interim-2016-lmap-1. The agenda is focused on the relevant IPPM work (especially the initial reg= istry content) and the ideas from Juergen about relation between the regist= ry and LMAP IM/DM and about translating the 'Run-time Parameters and Data F= ormat' and 'Output' formats into YANG definitions that hook into the data m= odel. In case there are other suggestions for the agenda, please let us know. As for any IETF meeting we need two note takers for the minutes. Please vol= unteer. Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEE0724AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Taking into account the inputs from Al and Juergen, = we shall proceed with holding the virtual interim meeting as planned, on Tu= esday 1/12/16, at 1PM ET.

 

Meeting information: http://www.ietf= .org/mail-archive/web/lmap/current/msg02369.html

 

The draft agenda is available at https://www.ietf.org/proceedings/interim/2016/01/12/lmap/agenda/agenda-inte= rim-2016-lmap-1.

 

The agenda is focused on the relevan= t IPPM work (especially the initial registry content) and the ideas from Ju= ergen about relation between the registry and LMAP IM/DM and about translating the 'Run-time Parameters and Data Format' and 'Outpu= t' formats into YANG definitions that hook into the data model.<= /span>

 

In case there are other suggestions = for the agenda, please let us know.

 

As for any IETF meeting we need two = note takers for the minutes. Please volunteer.

 

Thanks and Regards,

 

Jason and Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BEE0724AZFFEXMB04globa_-- From nobody Sun Jan 10 04:56:46 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 D54EB1ACCF5 for ; Sun, 10 Jan 2016 04:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 3STAE7u4MwVC for ; Sun, 10 Jan 2016 04:56:42 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 51F751A86EB for ; Sun, 10 Jan 2016 04:56:42 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id D924B12023F; Sun, 10 Jan 2016 07:55:08 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 1270BF0479; Sun, 10 Jan 2016 07:53:34 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Sun, 10 Jan 2016 07:53:33 -0500 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" , "Weil, Jason" Date: Sun, 10 Jan 2016 07:53:32 -0500 Thread-Topic: LMAP Virtual Interim meeting on 1/12 - Draft Agenda Thread-Index: AdFJT/xNmGBNCDvQSiSteG9RPkECaQCVMslA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D1D9ED663DF@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BEE0724@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BEE0724@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D1D9ED663DFNJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Cc: "Joachim Fabini \(Joachim.Fabini@tuwien.ac.at\)" , "Ackermann Michael \(MAckermann@bcbsm.com\)" , Vinayak Hegde , "Nalini Elkins \(nalini.elkins@insidethestack.com\)" Subject: Re: [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Agenda 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: Sun, 10 Jan 2016 12:56:45 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D1D9ED663DFNJFPSRVEXG0re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan and Jason, Regarding "other suggestions for the agenda", it may be useful to introduce this draft (already proposed to IPPM). https://tools.ietf.org/html/draft-morton-ippm-2330-stdform-typep-02 Without this update to the IPPM Framework, there is no accepted method to measure IPv6 with IPPM metrics, and limited accommodation of Diffserv/ECN and other IP Options. Clearly this is a proposal based on "time available", and intended only to widen the awareness/readership of the draft. regards, Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, January 07, 2016 8:33 AM To: lmap@ietf.org Subject: [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Agenda Hi, Taking into account the inputs from Al and Juergen, we shall proceed with h= olding the virtual interim meeting as planned, on Tuesday 1/12/16, at 1PM E= T. Meeting information: http://www.ietf.org/mail-archive/web/lmap/current/msg0= 2369.html The draft agenda is available at https://www.ietf.org/proceedings/interim/2= 016/01/12/lmap/agenda/agenda-interim-2016-lmap-1. The agenda is focused on the relevant IPPM work (especially the initial reg= istry content) and the ideas from Juergen about relation between the regist= ry and LMAP IM/DM and about translating the 'Run-time Parameters and Data F= ormat' and 'Output' formats into YANG definitions that hook into the data m= odel. In case there are other suggestions for the agenda, please let us know. As for any IETF meeting we need two note takers for the minutes. Please vol= unteer. Thanks and Regards, Jason and Dan --_000_4AF73AA205019A4C8A1DDD32C034631D1D9ED663DFNJFPSRVEXG0re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan and Jason,

Regarding “other suggestions for the ag= enda”, it may be

useful to introduce this draft= (already proposed to IPPM).

 <= /p>

https://tools.ietf.org/html/draft-morton-ippm-2330-stdform-typep-02=

 

= Without this update t= o the IPPM Framework, there is no

accepted method to = measure IPv6 with IPPM metrics, and limited

accommod= ation of Diffserv/ECN and other IP Options.

&nb= sp;

Clearly this is a proposal based on “time availab= le”,

and intended only to widen the awareness/re= adership of the draft.

 

reg= ards,

Al

 =

From: lmap [mailto:lmap-bounces= @ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursda= y, January 07, 2016 8:33 AM
To: lmap@ietf.org
Subject: = [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Agenda

 

Hi,

 

Taking into account the inputs from Al and Juergen, we shall p= roceed with holding the virtual interim meeting as planned, on Tuesday 1/12= /16, at 1PM ET.

 

Meeting information: http://www.ietf.org/mail-archive/web/lm= ap/current/msg02369.html

 

The draft agenda is available at https://www.ietf.org/proceedings/interim/2016/01/12= /lmap/agenda/agenda-interim-2016-lmap-1.

 

The agenda is focused on the re= levant IPPM work (especially the initial registry content) and the ideas fr= om Juergen about relation between the registry and LMAP IM/DM and about tra= nslating the 'Run-time Parameters and Data Format' and 'Output' formats int= o YANG definitions that hook into the data model.

 

In case there are= other suggestions for the agenda, please let us know.

 

As for any = IETF meeting we need two note takers for the minutes. Please volunteer.

 

Thanks and Regards,

 =

Jason and Dan

 

= --_000_4AF73AA205019A4C8A1DDD32C034631D1D9ED663DFNJFPSRVEXG0re_-- From nobody Sun Jan 10 06:25:04 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 A81FC1ACD7D for ; Sun, 10 Jan 2016 06:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.911 X-Spam-Level: X-Spam-Status: No, score=-4.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 lWX9pK55XsQq for ; Sun, 10 Jan 2016 06:25:01 -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 DE1861ACD79 for ; Sun, 10 Jan 2016 06:25:00 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AgAwA3Q8ZV/yYyC4dbGQEBAYIyISxUaQaFJ6RHBpM2CYFdHQEIhXoCgSY4FAEBAQEBAQGBCoQjAQEBAQMSG0UHEAIBCA0EBAEBCwsSBzIUCQgBAQQBDQUIARmIDAEMrGmgOgEBAQEBAQEBAQEBAQEBAQEBAQEBAReGH4UyhDAHAQEfLQQGAQkBgiRNHYEUBZULAYUBiSpGg1+DC4haiCoXD4Fggh1vAQEBgQIJFyOBBAEBAQ X-IPAS-Result: A2AgAwA3Q8ZV/yYyC4dbGQEBAYIyISxUaQaFJ6RHBpM2CYFdHQEIhXoCgSY4FAEBAQEBAQGBCoQjAQEBAQMSG0UHEAIBCA0EBAEBCwsSBzIUCQgBAQQBDQUIARmIDAEMrGmgOgEBAQEBAQEBAQEBAQEBAQEBAQEBAReGH4UyhDAHAQEfLQQGAQkBgiRNHYEUBZULAYUBiSpGg1+DC4haiCoXD4Fggh1vAQEBgQIJFyOBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208,217";a="160879823" 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; 10 Jan 2016 09:24:59 -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; 10 Jan 2016 09:24:58 -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; Sun, 10 Jan 2016 15:24:56 +0100 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" , "Weil, Jason" Thread-Topic: LMAP Virtual Interim meeting on 1/12 - Draft Agenda Thread-Index: AdFJT/xNmGBNCDvQSiSteG9RPkECaQCVMslAAANeUaA= Date: Sun, 10 Jan 2016 14:24:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEE354B@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BEE0724@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D1D9ED663DF@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D1D9ED663DF@NJFPSRVEXG0.research.att.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_9904FB1B0159DA42B0B887B7FA8119CA6BEE354BAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "Joachim Fabini \(Joachim.Fabini@tuwien.ac.at\)" , "Ackermann Michael \(MAckermann@bcbsm.com\)" , Vinayak Hegde , "Nalini Elkins \(nalini.elkins@insidethestack.com\)" Subject: Re: [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Agenda 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: Sun, 10 Jan 2016 14:25:03 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEE354BAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Al, Thanks for the update. This seems useful. There should not be a problem to = add this I-D to the 'IPPM relevant work' item that you already own in the a= genda. Thanks and Regards, Dan From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Sunday, January 10, 2016 2:54 PM To: Romascanu, Dan (Dan); lmap@ietf.org; Weil, Jason Cc: Joachim Fabini (Joachim.Fabini@tuwien.ac.at); Nalini Elkins (nalini.elk= ins@insidethestack.com); Ackermann Michael (MAckermann@bcbsm.com); Vinayak = Hegde Subject: RE: LMAP Virtual Interim meeting on 1/12 - Draft Agenda Hi Dan and Jason, Regarding "other suggestions for the agenda", it may be useful to introduce this draft (already proposed to IPPM). https://tools.ietf.org/html/draft-morton-ippm-2330-stdform-typep-02 Without this update to the IPPM Framework, there is no accepted method to measure IPv6 with IPPM metrics, and limited accommodation of Diffserv/ECN and other IP Options. Clearly this is a proposal based on "time available", and intended only to widen the awareness/readership of the draft. regards, Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, January 07, 2016 8:33 AM To: lmap@ietf.org Subject: [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Agenda Hi, Taking into account the inputs from Al and Juergen, we shall proceed with h= olding the virtual interim meeting as planned, on Tuesday 1/12/16, at 1PM E= T. Meeting information: http://www.ietf.org/mail-archive/web/lmap/current/msg0= 2369.html The draft agenda is available at https://www.ietf.org/proceedings/interim/2= 016/01/12/lmap/agenda/agenda-interim-2016-lmap-1. The agenda is focused on the relevant IPPM work (especially the initial reg= istry content) and the ideas from Juergen about relation between the regist= ry and LMAP IM/DM and about translating the 'Run-time Parameters and Data F= ormat' and 'Output' formats into YANG definitions that hook into the data m= odel. In case there are other suggestions for the agenda, please let us know. As for any IETF meeting we need two note takers for the minutes. Please vol= unteer. Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEE354BAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Al,

 

Thanks for the update.= This seems useful. There should not be a problem to add this I-D to the &#= 8216;IPPM relevant work’ item that you already own in the agenda.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: MORTON, = ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Sunday, January 10, 2016 2:54 PM
To: Romascanu, Dan (Dan); lmap@ietf.org; Weil, Jason
Cc: Joachim Fabini (Joachim.Fabini@tuwien.ac.at); Nalini Elkins (nal= ini.elkins@insidethestack.com); Ackermann Michael (MAckermann@bcbsm.com); V= inayak Hegde
Subject: RE: LMAP Virtual Interim meeting on 1/12 - Draft Agenda

 

Hi Dan and Jason,

 

Regarding “other suggestions for the agenda”, it ma= y be

useful to introduce this draft (already proposed to IPPM).=

 

https://tools= .ietf.org/html/draft-morton-ippm-2330-stdform-typep-02

 

Without this update to the IPPM Framework, there is no

accepted method to measure IPv6 with IPPM metrics, and limited<= o:p>

accommodation of Diffserv/ECN and other IP Options.<= /span>

 

Clearly this is a proposal based on “time available”= ;,

and intended only to widen the awareness/readership of the draf= t.

 

regards,

Al

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, January 07, 2016 8:33 AM
To: lmap@ietf.org
Subject: [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Agenda<= o:p>

 

Hi,

 

Taking into account the inputs from Al and Juergen, = we shall proceed with holding the virtual interim meeting as planned, on Tu= esday 1/12/16, at 1PM ET.

 

Meeting information: http://www.ietf.org/mail-archive/web/lmap/current/msg02369.html

 

The draft agenda is available at https://www.ietf.org/proceedings/interim/2016/01/12/lmap/agenda/agenda-inte= rim-2016-lmap-1.

 

The agenda is focused on the relevan= t IPPM work (especially the initial registry content) and the ideas from Ju= ergen about relation between the registry and LMAP IM/DM and about translating the 'Run-time Parameters and Data Format' and 'Outpu= t' formats into YANG definitions that hook into the data model.<= /span>

 

In case there are other suggestions = for the agenda, please let us know.

 

As for any IETF meeting we need two = note takers for the minutes. Please volunteer.

 

Thanks and Regards,

 

Jason and Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BEE354BAZFFEXMB04globa_-- From nobody Sun Jan 10 06:33:15 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 9D1BC1ACD89 for ; Sun, 10 Jan 2016 06:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 BNm6KeQqhLts for ; Sun, 10 Jan 2016 06:33:12 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 636291ACD87 for ; Sun, 10 Jan 2016 06:33:12 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id EC467121D02; Sun, 10 Jan 2016 09:34:43 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg11.research.att.com [135.207.255.123]) by mail-green.research.att.com (Postfix) with ESMTP id 0C74AE08B3; Sun, 10 Jan 2016 09:30:19 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG11.research.att.com ([fe80::516e:6eec:2697:ec78%17]) with mapi; Sun, 10 Jan 2016 09:33:08 -0500 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Date: Sun, 10 Jan 2016 09:33:07 -0500 Thread-Topic: LMAP Virtual Interim meeting on 1/12 - Draft Agenda Thread-Index: AdFJT/xNmGBNCDvQSiSteG9RPkECaQCY2/Wg Message-ID: <4AF73AA205019A4C8A1DDD32C034631D1D9ED663EC@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BEE0724@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BEE0724@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D1D9ED663ECNJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Agenda 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: Sun, 10 Jan 2016 14:33:14 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D1D9ED663ECNJFPSRVEXG0re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi LMAP, I'll add one draft to the reading list, to be covered briefly under the IPPM agenda item: https://tools.ietf.org/html/draft-morton-ippm-2330-stdform-typep-02 This is a proposed update to the IPPM Framework, as there is no accepted method to measure IPv6 with IPPM metrics, and limited accommodation of Diffserv/ECN and other IP Options. regards, Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, January 07, 2016 8:33 AM To: lmap@ietf.org Subject: [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Agenda Hi, Taking into account the inputs from Al and Juergen, we shall proceed with h= olding the virtual interim meeting as planned, on Tuesday 1/12/16, at 1PM E= T. Meeting information: http://www.ietf.org/mail-archive/web/lmap/current/msg0= 2369.html The draft agenda is available at https://www.ietf.org/proceedings/interim/2= 016/01/12/lmap/agenda/agenda-interim-2016-lmap-1. The agenda is focused on the relevant IPPM work (especially the initial reg= istry content) and the ideas from Juergen about relation between the regist= ry and LMAP IM/DM and about translating the 'Run-time Parameters and Data F= ormat' and 'Output' formats into YANG definitions that hook into the data m= odel. In case there are other suggestions for the agenda, please let us know. As for any IETF meeting we need two note takers for the minutes. Please vol= unteer. Thanks and Regards, Jason and Dan --_000_4AF73AA205019A4C8A1DDD32C034631D1D9ED663ECNJFPSRVEXG0re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi LMAP,

&n= bsp;

I’ll add one draft to the reading list, to be co= vered briefly under the

IPPM agenda item:

https://tools.ie= tf.org/html/draft-morton-ippm-2330-stdform-typep-02

This is a proposed update to the IPPM Framework, as there i= s no

accepted method to measure IPv6 with IPPM metric= s, and limited

accommodation of Diffserv/ECN and other= IP Options.

 

regards,=

Al

 

 

From: lmap = [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
= Sent: Thursday, January 07, 2016 8:33 AM
To: lmap@ietf.org=
Subject: [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Age= nda

 =

Hi,

 =

Taking into account the inputs from Al and J= uergen, we shall proceed with holding the virtual interim meeting as planne= d, on Tuesday 1/12/16, at 1PM ET.

&= nbsp;

Meeting information: http://www.ietf.org/m= ail-archive/web/lmap/current/msg02369.html

 

The draft agenda is= available at https://www.ietf.org/proceedings/= interim/2016/01/12/lmap/agenda/agenda-interim-2016-lmap-1. <= /p>

 

The agenda is= focused on the relevant IPPM work (especially the initial registry content= ) and the ideas from Juergen about relation between the registry and LMAP I= M/DM and about translating the 'Run-time Parameters and Data Format' and 'O= utput' formats into YANG definitions that hook into the data model.

 

In case there are other suggestions for the agenda, please let us know.

 

As for any IETF meeting we need two note takers for the minutes. P= lease volunteer.

 <= /span>

Thanks and Regards,

 

Jason and Dan=

 

<= /body>= --_000_4AF73AA205019A4C8A1DDD32C034631D1D9ED663ECNJFPSRVEXG0re_-- From nobody Tue Jan 12 01:15:50 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 7DC201A6F33 for ; Tue, 12 Jan 2016 01:15:47 -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 1Yn3WXTWQOV6 for ; Tue, 12 Jan 2016 01:15:46 -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 E1E3B1A6F13 for ; Tue, 12 Jan 2016 01:15:45 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D5AQCuw5RW/yYyC4deGQEBAQEPAQEBAYI+ISsiMG0GiFOxHIITAQ2BYQUYAQuFawKBKTgUAQEBAQEBAX8LhDYBAQMSG14BDAkVViYBBBsBGYgMAQ2fR4USmwUBAQgBAQEBH4ZYhH2ENwEBHi2CNgxBG4EbBZcTAZcXhT2OUyABAUKECnIBhG46AYEHAQEB X-IPAS-Result: A2D5AQCuw5RW/yYyC4deGQEBAQEPAQEBAYI+ISsiMG0GiFOxHIITAQ2BYQUYAQuFawKBKTgUAQEBAQEBAX8LhDYBAQMSG14BDAkVViYBBBsBGYgMAQ2fR4USmwUBAQgBAQEBH4ZYhH2ENwEBHi2CNgxBG4EbBZcTAZcXhT2OUyABAUKECnIBhG46AYEHAQEB X-IronPort-AV: E=Sophos;i="5.20,556,1444708800"; d="scan'208,217";a="161083903" 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; 12 Jan 2016 04:15:44 -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; 12 Jan 2016 04:15:45 -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; Tue, 12 Jan 2016 10:15:43 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Reminder - LMAP WG Virtual Interim - TODAY Thread-Index: AdFNGc91AQFbxOxqSH2U30pj7Sy94w== Date: Tue, 12 Jan 2016 09:15:42 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEE4D28@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_9904FB1B0159DA42B0B887B7FA8119CA6BEE4D28AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Reminder - LMAP WG Virtual Interim - TODAY 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: Tue, 12 Jan 2016 09:15:47 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEE4D28AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a reminder that the LMAP WG Virtual Interim meeting is scheduled fo= r today, starting at 1PM ET. The meeting agenda is available at https://www.ietf.org/proceedings/interim= /2016/01/12/lmap/agenda/agenda-interim-2016-lmap-1 Meeting information: http://www.ietf.org/mail-archive/web/lmap/current/msg0= 2369.html We still need two volunteers to take notes for the minutes. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEE4D28AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This is a reminder that the LMAP WG Virtual Interim = meeting is scheduled for today, starting at 1PM ET.

 

The meeting agenda is available at https://www.ietf.org/proceedings/interim/2016/01/12/lmap/agenda/agenda-inte= rim-2016-lmap-1

 

Meeting information: http://www.ietf.org/mail-archive/web/lmap/current/msg02369.html

 

We still need two volunteers to take notes for the m= inutes.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BEE4D28AZFFEXMB04globa_-- From nobody Tue Jan 12 05:01:30 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 DF4161A899C for ; Tue, 12 Jan 2016 05:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 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.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 wVDSVBZilmpN for ; Tue, 12 Jan 2016 05:01:27 -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 910D71AD0C4 for ; Tue, 12 Jan 2016 05:01:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4EAAC8DA; Tue, 12 Jan 2016 14:01: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 vBiO3jFpVYpS; Tue, 12 Jan 2016 14:01:23 +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, 12 Jan 2016 14:01:23 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C7E420013; Tue, 12 Jan 2016 14:01:23 +0100 (CET) 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 XHRDlFSzHFvv; Tue, 12 Jan 2016 14:01: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 54EBD2002B; Tue, 12 Jan 2016 14:01:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 307373982B51; Tue, 12 Jan 2016 14:01:19 +0100 (CET) Date: Tue, 12 Jan 2016 14:01:19 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160112130116.GA5423@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA6BEE0724@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BEE0724@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Virtual Interim meeting on 1/12 - Draft Agenda 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, 12 Jan 2016 13:01:29 -0000 On Thu, Jan 07, 2016 at 01:33:26PM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > Taking into account the inputs from Al and Juergen, we shall proceed with holding the virtual interim meeting as planned, on Tuesday 1/12/16, at 1PM ET. > > > Meeting information: http://www.ietf.org/mail-archive/web/lmap/current/msg02369.html > > The draft agenda is available at https://www.ietf.org/proceedings/interim/2016/01/12/lmap/agenda/agenda-interim-2016-lmap-1. > > > The agenda is focused on the relevant IPPM work (especially the initial registry content) and the ideas from Juergen about relation between the registry and LMAP IM/DM and about translating the 'Run-time Parameters and Data Format' and 'Output' formats into YANG definitions that hook into the data model. > I have created some slides for my part of the interim meeting: https://www.ietf.org/proceedings/interim/2016/01/12/lmap/slides/slides-interim-2016-lmap-1-0.pdf /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From Ron.Stana@viavisolutions.com Tue Jan 12 09:02:48 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 4E2DA1B2B50 for ; Tue, 12 Jan 2016 09:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Iw3x3tpgZYPF for ; Tue, 12 Jan 2016 09:02:41 -0800 (PST) Received: from mx0b-00158d01.pphosted.com (mx0b-00158d01.pphosted.com [67.231.152.180]) (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 D633D1B2B64 for ; Tue, 12 Jan 2016 09:02:40 -0800 (PST) Received: from pps.filterd (m0043258.ppops.net [127.0.0.1]) by mx0b-00158d01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u0CGc0JL018080; Tue, 12 Jan 2016 09:02:38 -0800 Received: from mx5.jdsu.com ([157.234.214.240]) by mx0b-00158d01.pphosted.com with ESMTP id 20b1jqucq1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Jan 2016 09:02:37 -0800 Received: from AMEXJR02.ds.jdsu.net (10.106.72.52) by MX5.jdsu.com (10.239.15.240) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 12 Jan 2016 09:02:41 -0800 Received: from AMEXMB01.ds.jdsu.net ([fe80::9402:2c4c:29f3:a264]) by AMEXJR02.ds.jdsu.net ([::1]) with mapi id 14.03.0266.001; Tue, 12 Jan 2016 09:02:36 -0800 From: Ron Stana To: "lmap@ietf.org" Thread-Topic: LMAP Result Correlation Thread-Index: AdFNWvvfnq5l1gSvQJ6Lk6mwMGzwLg== Date: Tue, 12 Jan 2016 17:02:36 +0000 Message-ID: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.234.110.232] Content-Type: multipart/alternative; boundary="_000_9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9AMEXMB01dsjdsun_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-12_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601120283 Archived-At: X-Mailman-Approved-At: Tue, 12 Jan 2016 09:05:04 -0800 Cc: "alissa@cooperw.in" Subject: [lmap] LMAP Result Correlation 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: Tue, 12 Jan 2016 17:03:43 -0000 --_000_9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9AMEXMB01dsjdsun_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alissa, LMAP Team, Regarding the September 2015 version of A Framework for Large-Scale Measure= ment of Broadband Performance [LMAP], I am trying to determine how multiple= result sets for a given schedule instance/execution can be correlated. I think my questions are best illustrated using a couple scenarios: Scenario #1: 1. Schedule A is configured to execute Monday@ 9:00am for 1 hour 2. Schedule B is configured to execute Tuesday @ 9:00am for 1 hour 3. Both schedules reference the same task and use the same task confi= gurations thus they are measuring the same network measurement but at diffe= rent times. 4. Intermediate results are sent to the collector periodically while = the schedule executes and then final results are sent once it completes. 5. What in the results can be used to know which sets of results belo= ng to a single execution of the same schedule instance (example: Schedule A= )? This is my interpretation of LMAP; item #3 seems to address the need. Item 1: The ietf-lmap-report path report/input/date is the time each result= set was sent to the collector so that will be unique for each set of resul= ts and so cannot be used. Item 2: The report/input/task/name will be the same across the results from= the different schedules since they are both executing the same task so tha= t cannot be used. Item 3: The report/input/task/row/start value would be the same across resu= lts from a given schedule instance (ie. the Monday run) and yet unique acro= ss schedule instances (ie Mon vs Tues run) so it could be used. 6. What in the results can be used to know which sets of results belo= ng to all executions of the same schedule instance (example: Schedule A)? Scenario #2: While Item #3 above can address part of Scenario #1, it does not address th= is additional scenario: 1. Schedule A is performing a Performance Monitoring task (ex. TWAMP)= and so is configured for immediate and startup execution/events so it shou= ld always be running. 2. The task is sending results to the collector periodically during e= xecution. 3. The device hosting the MA is rebooted so the MA restarts the sched= ule/task execution. Thus the report/input/task/row/start value would be di= fferent in the results sent after the restart. 4. Since the same schedule/task definition is producing the results b= efore and after the MA restart, they logically belong to the same schedule = execution. 5. What can be used to group the results from before and after the re= start together? Adding the schedule name to report/input/task would help but since the sche= dule name can be reused, it does not infer a specific schedule instance. Adding something like an 'initial schedule start' to report/input/task, whe= re it is the date/time the schedule started the very first time (thus not c= hanging across MA restarts), seems to provide the needed association betwee= n the result sets. This could be abstracted to a 'schedule id' since it co= uld alternatively be a unique id assigned to each schedule by the Controlle= r. While a custom value like this could be placed in report/input/task/tag= or report/input/task/option I wanted to know if a common approach existed = or was planned. Thank you, Ron --_000_9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9AMEXMB01dsjdsun_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alissa, LMAP Team,

Regarding the Septembe= r 2015 version of A Framework for Large-Scale Measurement of Broadband= Performance [LMAP], I am trying to determine how multiple result sets for = a given schedule instance/execution can be correlated.

I think my ques= tions are best illustrated using a couple scenarios:

Scenario #1:

1.&nb= sp;      2.&nb= sp;      3.&nb= sp;      4.&nb= sp;      5.&nb= sp;      Item 1: The ietf-lmap-report path report/input/date is the tim= e each result set was sent to the collector so that will be unique for each set of results and so cannot be used.

Item 2: The report/input/task/name will be the same across the= results from the different schedules since they are both executing the same task so that cannot be used.=

Item 3: The report/input/task/row/star= t value would be the same across results from a given schedule instance (ie= . the Monday run) and yet unique across schedule instances (ie Mon vs Tues run) so it could be used.

 

6.&nb= sp;      Scenario #2:

While Item #3 a= bove can address part of Scenario #1, it does not address this additional s= cenario:

1.&nb= sp;      2.&nb= sp;      3.&nb= sp;      4.&nb= sp;      5.&nb= sp;      Adding the sche= dule name to report/input/task would help but since the schedule name can b= e reused, it does not infer a specific schedule instance.=

Adding somethin= g like an ‘initial schedule start’ to report/input/task, where = it is the date/time the schedule started the very first time (thus not changing across MA restarts), seems to provide the needed association betw= een the result sets.  This could be abstracted to a ‘schedule id= ’ since it could alternatively be a unique id assigned to each schedu= le by the Controller.  While a custom value like this could be placed in report/input/task/tag or report/input/task/option = I wanted to know if a common approach existed or was planned.

Thank you,=

Ron<= /span>

 

 

--_000_9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9AMEXMB01dsjdsun_-- From nobody Wed Jan 13 04:27:13 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 BC7A71A6F8E; Wed, 13 Jan 2016 04:26:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160113122640.17508.47215.idtracker@ietfa.amsl.com> Date: Wed, 13 Jan 2016 04:26:40 -0800 Archived-At: X-Mailman-Approved-At: Wed, 13 Jan 2016 04:27:12 -0800 Cc: dromasca@avaya.com, lmap-chairs@ietf.org, alissa@cooperw.in, lmap@ietf.org Subject: [lmap] lmap - New Meeting Session Request for IETF 95 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 12:26:40 -0000 A new meeting session request has just been submitted by Dan Romascanu, a Chair of the lmap working group. --------------------------------------------------------- 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 Wed Jan 13 04:33:27 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 A794D1ACDA3 for ; Wed, 13 Jan 2016 04:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 PYzMcNe75pAR for ; Wed, 13 Jan 2016 04:33:24 -0800 (PST) Received: from worker3.doodle.com (worker3.doodle.com [94.230.219.153]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425EB1ACDA1 for ; Wed, 13 Jan 2016 04:33:24 -0800 (PST) Received: from worker3.doodle.com (localhost [127.0.0.1]) by worker3.doodle.com (Postfix) with ESMTP id 61FDCC010D1 for ; Wed, 13 Jan 2016 13:33:22 +0100 (CET) Date: Wed, 13 Jan 2016 13:33:22 +0100 (CET) From: "Dan Romascanu (via Doodle)" To: lmap@ietf.org Message-ID: <1412650055.2331574.1452688402399.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE@worker3.doodle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2331573_1423520848.1452688402399" Archived-At: Subject: [lmap] LMAP Virtual Interim Meeting - February 2016 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Dan Romascanu List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 12:33:26 -0000 ------=_Part_2331573_1423520848.1452688402399 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi there, Dan Romascanu (dromasca@avaya.com) invites you to participate in the Doodle poll "LMAP Virtual Interim Meeting - February 2016." Virtual Meeting of the IETF LMAP Working Group. Participate now https://doodle.com/poll/e82b5iuadkg6k9xa?tmail=3Dpoll_invitecontact_partici= pant_invitation_with_message&tlink=3Dpollbtn What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/features?tlink=3DcheckOutLink&tmail=3Dpoll_invitecontac= t_participant_invitation_with_message) ---------------------------------------------------------------------- You have received this e-mail because "Dan Romascanu" has invited you to participate in the Doodle poll "LMAP Virtual Interim Meeting - February 2016." ---- Doodle is also available for iOS and Android. ---- Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich ------=_Part_2331573_1423520848.1452688402399 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =
Dan Romascanu invites you to p= articipate in the Doodle poll "LMAP Virtual Interim Meeting - February= 2016."
=09
=20
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09 =09 =09 =09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
"LMAP Virtual= Interim Meeting - February 2016." =09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09Virtual Meeting of the IETF LMAP Working Group. =09=09=09=09=09=09
=09=09=09=09=09
=20 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=
=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09=09=09Participate n= ow =09=09=09=09=09=09=09
=09=09=09=09=09
=
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09
=09=09=09=09=09=09=09 What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date= for meeting with a group of people. Learn more about how Doodle works.
=09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09
=09=09 =09You have received this e-mail because "Dan Romascanu&= quot; has invited you to participate in the Doodle poll "LMAP Virtual = Interim Meeting - February 2016." =09=09
=09
Doodle is also available for iOS and Android.
Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich

------=_Part_2331573_1423520848.1452688402399-- From nobody Thu Jan 21 08:56:38 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 A27EC1B32F9 for ; Thu, 21 Jan 2016 08:56:37 -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 BraN0oMy-d2h for ; Thu, 21 Jan 2016 08:56:36 -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 1B2381B32F8 for ; Thu, 21 Jan 2016 08:56:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ALAgBiDaFW/xUHmMZeGQEBAQEPAQECgj4hK1JuBYhRsh4BDYFiIoVtAoE9OBQBAQEBAQEBfwuENgEBAxIbXgEMCRVWJgEEGxqHeQENnkOFEpoiHoY6hHKETYMsgQ8FlnUBhUWJb0qDeoMbhTyOPB4BAUKDZocRAXsBAQE X-IPAS-Result: A2ALAgBiDaFW/xUHmMZeGQEBAQEPAQECgj4hK1JuBYhRsh4BDYFiIoVtAoE9OBQBAQEBAQEBfwuENgEBAxIbXgEMCRVWJgEEGxqHeQENnkOFEpoiHoY6hHKETYMsgQ8FlnUBhUWJb0qDeoMbhTyOPB4BAUKDZocRAXsBAQE X-IronPort-AV: E=Sophos;i="5.22,326,1449550800"; d="scan'208,217";a="162739070" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 Jan 2016 11:56:34 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 21 Jan 2016 11:56:34 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Thu, 21 Jan 2016 17:56:33 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Reminder - Doodle poll for February Virtual Interim Meeting Thread-Index: AdFUbK3Y3FeP/TVARvCrHtOn47N4Pw== Date: Thu, 21 Jan 2016 16:56:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEF31F5@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_9904FB1B0159DA42B0B887B7FA8119CA6BEF31F5AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Reminder - Doodle poll for February Virtual Interim Meeting 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: Thu, 21 Jan 2016 16:56:37 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF31F5AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a reminder that we have an ongoing Doodle poll open to select a dat= e for a second virtual interim meeting of the LMAP WG between IETF 94 and I= ETF 94. The link is http://doodle.com/poll/e82b5iuadkg6k9xa. Very few people expressed their preferences. Please do it soon, as February= is not that far away and we need to decide on a date and time two weeks in= advance. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF31F5AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This is a reminder that we have an ongoing Doodle po= ll open to select a date for a second virtual interim meeting of the LMAP W= G between IETF 94 and IETF 94.

 

The link is http://doodle.com/poll/e82b5iuadkg6k9xa.

 

Very few people expressed their preferences. Please = do it soon, as February is not that far away and we need to decide on a dat= e and time two weeks in advance.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF31F5AZFFEXMB04globa_-- From nobody Thu Jan 21 09:35:13 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 147271B335D for ; Thu, 21 Jan 2016 09:35:12 -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 xrLmZMbWhCAG for ; Thu, 21 Jan 2016 09:35:10 -0800 (PST) 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 7DD271A6EF1 for ; Thu, 21 Jan 2016 09:35:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,322,1449550800"; d="scan'208,217";a="157072721" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Jan 2016 12:35:09 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 21 Jan 2016 12:35:09 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Thu, 21 Jan 2016 18:35:07 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: draft minutes of the 1/12/16 virtual interim meeting Thread-Index: AdFUcg71xXgH7SneRxmyImqvW1PCnQ== Date: Thu, 21 Jan 2016 17:35:07 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEF327D@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_9904FB1B0159DA42B0B887B7FA8119CA6BEF327DAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft minutes of the 1/12/16 virtual interim meeting 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: Thu, 21 Jan 2016 17:35:12 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF327DAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The minutes of the LMAP WG virtual interim meeting from January 12, 2016 ar= e available at https://www.ietf.org/proceedings/interim/2016/01/12/lmap/min= utes/minutes-interim-2016-lmap-1. Thanks to Barbara and Holger for taking t= he notes that made the minutes possible. Please read and comment if I misse= d anything important or I recorded anything wrong. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF327DAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The minutes of the LMAP WG virtual interim meeting f= rom January 12, 2016 are available at https://www.ietf.org/proceedings/interim/2016/01/12/lmap/minutes/minutes-in= terim-2016-lmap-1. Thanks to Barbara and Holger for taking the notes th= at made the minutes possible. Please read and comment if I missed anything = important or I recorded anything wrong.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF327DAZFFEXMB04globa_-- From nobody Tue Jan 26 03:16:38 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 382921AD0C2 for ; Tue, 26 Jan 2016 03:16:37 -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 RrfU9ekTVkiW for ; Tue, 26 Jan 2016 03:16:35 -0800 (PST) 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 A41541AD0B8 for ; Tue, 26 Jan 2016 03:16:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D5AQBBVadW/xUHmMZeGQEBAQEPAQEBAYI+IStSbQaFNIMdshoBDYFjH4VwAoFGOBQBAQEBAQEBfwuEQQEBAQEDEhtcAgEIDQQEAQELHQcyFAkIAQEEEwgah3kBDaRZmWsBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhjSEa4RLLQmCdoEPBZZ5AYVFiW5Kg3qDG4U8inCDUx4BAUKDaWoBh0cBewEBAQ X-IPAS-Result: A2D5AQBBVadW/xUHmMZeGQEBAQEPAQEBAYI+IStSbQaFNIMdshoBDYFjH4VwAoFGOBQBAQEBAQEBfwuEQQEBAQEDEhtcAgEIDQQEAQELHQcyFAkIAQEEEwgah3kBDaRZmWsBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhjSEa4RLLQmCdoEPBZZ5AYVFiW5Kg3qDG4U8inCDUx4BAUKDaWoBh0cBewEBAQ X-IronPort-AV: E=Sophos;i="5.22,350,1449550800"; d="scan'208,217";a="157787182" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Jan 2016 06:16:34 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 26 Jan 2016 06:16:34 -0500 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; Tue, 26 Jan 2016 06:16:28 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Reminder - Doodle poll for February Virtual Interim Meeting Thread-Index: AdFUbK3Y3FeP/TVARvCrHtOn47N4PwDvikxQ Date: Tue, 26 Jan 2016 11:16:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEF8977@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BEF31F5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BEF31F5@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_9904FB1B0159DA42B0B887B7FA8119CA6BEF8977AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Reminder - Doodle poll for February Virtual Interim Meeting 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: Tue, 26 Jan 2016 11:16:37 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF8977AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One more reminder! Please express your preferences for the day and time of = the next LMAP virtual interim! Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, January 21, 2016 6:57 PM To: lmap@ietf.org Subject: [lmap] Reminder - Doodle poll for February Virtual Interim Meeting Hi, This is a reminder that we have an ongoing Doodle poll open to select a dat= e for a second virtual interim meeting of the LMAP WG between IETF 94 and I= ETF 94. The link is http://doodle.com/poll/e82b5iuadkg6k9xa. Very few people expressed their preferences. Please do it soon, as February= is not that far away and we need to decide on a date and time two weeks in= advance. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF8977AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One more reminder! Ple= ase express your preferences for the day and time of the next LMAP virtual = interim!

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, January 21, 2016 6:57 PM
To: lmap@ietf.org
Subject: [lmap] Reminder - Doodle poll for February Virtual Interim = Meeting

 

Hi,

 

This is a reminder that we have an ongoing Doodle po= ll open to select a date for a second virtual interim meeting of the LMAP W= G between IETF 94 and IETF 94.

 

The link is http://doodle.com/poll/e82b5iuadkg6k9xa.

 

Very few people expressed their preferences. Please = do it soon, as February is not that far away and we need to decide on a dat= e and time two weeks in advance.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF8977AZFFEXMB04globa_-- From nobody Wed Jan 27 06:04:42 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 96D341B2E03 for ; Wed, 27 Jan 2016 06:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 QBBhzuBQHZpY for ; Wed, 27 Jan 2016 06:04:39 -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 ABB241B2DFA for ; Wed, 27 Jan 2016 06:04:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AF6EE1044; Wed, 27 Jan 2016 15:04:36 +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 P8weHEiU7T8w; Wed, 27 Jan 2016 15:04:35 +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; Wed, 27 Jan 2016 15:04:35 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7294B20035; Wed, 27 Jan 2016 15:04:35 +0100 (CET) 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 JFa4Q2GVkDZN; Wed, 27 Jan 2016 15:04:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C669C20038; Wed, 27 Jan 2016 15:04:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DB8E939C3CDB; Wed, 27 Jan 2016 15:04:29 +0100 (CET) Date: Wed, 27 Jan 2016 15:04:29 +0100 From: Juergen Schoenwaelder To: Ron Stana Message-ID: <20160127140429.GB56525@elstar.local> Mail-Followup-To: Ron Stana , "lmap@ietf.org" , "alissa@cooperw.in" References: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] LMAP Result Correlation 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: Wed, 27 Jan 2016 14:04:41 -0000 On Tue, Jan 12, 2016 at 05:02:36PM +0000, Ron Stana wrote: > Alissa, LMAP Team, > Regarding the September 2015 version of A Framework for Large-Scale Measurement of Broadband Performance [LMAP], I am trying to determine how multiple result sets for a given schedule instance/execution can be correlated. > I think my questions are best illustrated using a couple scenarios: > Scenario #1: > > 1. Schedule A is configured to execute Monday@ 9:00am for 1 hour > > 2. Schedule B is configured to execute Tuesday @ 9:00am for 1 hour > > 3. Both schedules reference the same task and use the same task configurations thus they are measuring the same network measurement but at different times. > > 4. Intermediate results are sent to the collector periodically while the schedule executes and then final results are sent once it completes. > > 5. What in the results can be used to know which sets of results belong to a single execution of the same schedule instance (example: Schedule A)? This is my interpretation of LMAP; item #3 seems to address the need. > Item 1: The ietf-lmap-report path report/input/date is the time each result set was sent to the collector so that will be unique for each set of results and so cannot be used. > Item 2: The report/input/task/name will be the same across the results from the different schedules since they are both executing the same task so that cannot be used. > > Item 3: The report/input/task/row/start value would be the same across results from a given schedule instance (ie. the Monday run) and yet unique across schedule instances (ie Mon vs Tues run) so it could be used. > > > 6. What in the results can be used to know which sets of results belong to all executions of the same schedule instance (example: Schedule A)? I think you can configure two different tasks with different tags and since the tags are reported and the task name, you can distinguish things. Whether this is practical or whether it should also be possible to set tags on an action is perhaps something to discuss. > Scenario #2: > While Item #3 above can address part of Scenario #1, it does not address this additional scenario: > > 1. Schedule A is performing a Performance Monitoring task (ex. TWAMP) and so is configured for immediate and startup execution/events so it should always be running. > > 2. The task is sending results to the collector periodically during execution. > > 3. The device hosting the MA is rebooted so the MA restarts the schedule/task execution. Thus the report/input/task/row/start value would be different in the results sent after the restart. > > 4. Since the same schedule/task definition is producing the results before and after the MA restart, they logically belong to the same schedule execution. > > 5. What can be used to group the results from before and after the restart together? I think the mechanism to group measurements belonging logically together tags. Looking at time stamps to group things is likely brittle. > Adding the schedule name to report/input/task would help but since the schedule name can be reused, it does not infer a specific schedule instance. While having the schedule name may help in some situations, it won't in others. I think we should rather use tags that have no other meaning. This allows for example to rename schedules etc. In fact, I would prefer not to expose the details how something got scheduled to the collector. It should not matter much to the collector whether I use multiple schedules bound to the same event with one action each or a single schedule bound to the event with multiple concurrent actions. > Adding something like an 'initial schedule start' to report/input/task, where it is the date/time the schedule started the very first time (thus not changing across MA restarts), seems to provide the needed association between the result sets. This could be abstracted to a 'schedule id' since it could alternatively be a unique id assigned to each schedule by the Controller. I would rather not put a requirement into the data model that an lmap implementation has to manage persistent state. > While a custom value like this could be placed in report/input/task/tag or report/input/task/option I wanted to know if a common approach existed or was planned. I think the tag was designed for this purpose, namely to be able to correlate results that logically belong together. /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 Thu Jan 28 00:29:19 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 68B7E1ACDC4 for ; Thu, 28 Jan 2016 00:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 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.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 ZFH9y03-8AdW for ; Thu, 28 Jan 2016 00:29:15 -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 71E5E1ACDBE for ; Thu, 28 Jan 2016 00:29:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 708B6FB1; Thu, 28 Jan 2016 09:29:13 +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 P0O0cSCcP9hu; Thu, 28 Jan 2016 09:29:12 +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; Thu, 28 Jan 2016 09:29:12 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E15F920031; Thu, 28 Jan 2016 09:29:11 +0100 (CET) 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 JhYavyW2aIP4; Thu, 28 Jan 2016 09:29: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 3D1102002C; Thu, 28 Jan 2016 09:29:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9C05639C494C; Thu, 28 Jan 2016 09:29:06 +0100 (CET) Date: Thu, 28 Jan 2016 09:29:05 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160128082904.GA1957@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , Ron Stana , "alissa@cooperw.in" , "lmap@ietf.org" References: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> <20160127140429.GB56525@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B1903@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A5B1903@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "alissa@cooperw.in" , Ron Stana , "lmap@ietf.org" Subject: Re: [lmap] LMAP Result Correlation 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: Thu, 28 Jan 2016 08:29:18 -0000 Tim, how does this observation related to the discussion? The YANG model includes the task name and the metric URIs in the report. This is inline with ma-report-task-obj in the information model. The place where the report YANG data model differs from the information model is the ma-report-task-cycle-id: the YANG data model allows for a set of tags instead of a single cycle-id. /js On Wed, Jan 27, 2016 at 10:50:12PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > In the TR-069 data model we report the name of the task (not registry entry) that was used in the report information. This is part of the ma-report-task-obj.... > > BR, > Tim > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 27, 2016 8:04 AM > To: Ron Stana > Cc: alissa@cooperw.in; lmap@ietf.org > Subject: Re: [lmap] LMAP Result Correlation > > On Tue, Jan 12, 2016 at 05:02:36PM +0000, Ron Stana wrote: > > Alissa, LMAP Team, > > Regarding the September 2015 version of A Framework for Large-Scale Measurement of Broadband Performance [LMAP], I am trying to determine how multiple result sets for a given schedule instance/execution can be correlated. > > I think my questions are best illustrated using a couple scenarios: > > Scenario #1: > > > > 1. Schedule A is configured to execute Monday@ 9:00am for 1 hour > > > > 2. Schedule B is configured to execute Tuesday @ 9:00am for 1 hour > > > > 3. Both schedules reference the same task and use the same task configurations thus they are measuring the same network measurement but at different times. > > > > 4. Intermediate results are sent to the collector periodically while the schedule executes and then final results are sent once it completes. > > > > 5. What in the results can be used to know which sets of results belong to a single execution of the same schedule instance (example: Schedule A)? This is my interpretation of LMAP; item #3 seems to address the need. > > Item 1: The ietf-lmap-report path report/input/date is the time each result set was sent to the collector so that will be unique for each set of results and so cannot be used. > > Item 2: The report/input/task/name will be the same across the results from the different schedules since they are both executing the same task so that cannot be used. > > > > Item 3: The report/input/task/row/start value would be the same across results from a given schedule instance (ie. the Monday run) and yet unique across schedule instances (ie Mon vs Tues run) so it could be used. > > > > > > 6. What in the results can be used to know which sets of results belong to all executions of the same schedule instance (example: Schedule A)? > > I think you can configure two different tasks with different tags and since the tags are reported and the task name, you can distinguish things. Whether this is practical or whether it should also be possible to set tags on an action is perhaps something to discuss. > > > Scenario #2: > > While Item #3 above can address part of Scenario #1, it does not address this additional scenario: > > > > 1. Schedule A is performing a Performance Monitoring task (ex. TWAMP) and so is configured for immediate and startup execution/events so it should always be running. > > > > 2. The task is sending results to the collector periodically during execution. > > > > 3. The device hosting the MA is rebooted so the MA restarts the schedule/task execution. Thus the report/input/task/row/start value would be different in the results sent after the restart. > > > > 4. Since the same schedule/task definition is producing the results before and after the MA restart, they logically belong to the same schedule execution. > > > > 5. What can be used to group the results from before and after the restart together? > > I think the mechanism to group measurements belonging logically together tags. Looking at time stamps to group things is likely brittle. > > > Adding the schedule name to report/input/task would help but since the schedule name can be reused, it does not infer a specific schedule instance. > > While having the schedule name may help in some situations, it won't in others. I think we should rather use tags that have no other meaning. This allows for example to rename schedules etc. In fact, I would prefer not to expose the details how something got scheduled to the collector. It should not matter much to the collector whether I use multiple schedules bound to the same event with one action each or a single schedule bound to the event with multiple concurrent actions. > > > Adding something like an 'initial schedule start' to report/input/task, where it is the date/time the schedule started the very first time (thus not changing across MA restarts), seems to provide the needed association between the result sets. This could be abstracted to a 'schedule id' since it could alternatively be a unique id assigned to each schedule by the Controller. > > I would rather not put a requirement into the data model that an lmap implementation has to manage persistent state. > > > While a custom value like this could be placed in report/input/task/tag or report/input/task/option I wanted to know if a common approach existed or was planned. > > I think the tag was designed for this purpose, namely to be able to correlate results that logically belong together. > > /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 Thu Jan 28 04:53:30 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 4BE021B2EBA for ; Wed, 27 Jan 2016 14:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 4OjIXQ0x7_G1 for ; Wed, 27 Jan 2016 14:50:17 -0800 (PST) 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 241EC1B2D05 for ; Wed, 27 Jan 2016 14:50:17 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 157F09CB327B; Wed, 27 Jan 2016 22:50:12 +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 u0RMoEWW030944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jan 2016 22:50:14 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 u0RMoClw030180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jan 2016 22:50:13 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.82]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Wed, 27 Jan 2016 17:50:12 -0500 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , Ron Stana Thread-Topic: [lmap] LMAP Result Correlation Thread-Index: AQHRWT1zdQZ+9uOJak2nQiJ7JPqUTZ8P9GBg Date: Wed, 27 Jan 2016 22:50:12 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5B1903@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> <20160127140429.GB56525@elstar.local> In-Reply-To: <20160127140429.GB56525@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: X-Mailman-Approved-At: Thu, 28 Jan 2016 04:53:28 -0800 Cc: "alissa@cooperw.in" , "lmap@ietf.org" Subject: Re: [lmap] LMAP Result Correlation 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, 27 Jan 2016 22:50:19 -0000 Juergen, In the TR-069 data model we report the name of the task (not registry entry= ) that was used in the report information. This is part of the ma-report-t= ask-obj.... BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, January 27, 2016 8:04 AM To: Ron Stana Cc: alissa@cooperw.in; lmap@ietf.org Subject: Re: [lmap] LMAP Result Correlation On Tue, Jan 12, 2016 at 05:02:36PM +0000, Ron Stana wrote: > Alissa, LMAP Team, > Regarding the September 2015 version of A Framework for Large-Scale Measu= rement of Broadband Performance [LMAP], I am trying to determine how multip= le result sets for a given schedule instance/execution can be correlated. > I think my questions are best illustrated using a couple scenarios: > Scenario #1: >=20 > 1. Schedule A is configured to execute Monday@ 9:00am for 1 hour >=20 > 2. Schedule B is configured to execute Tuesday @ 9:00am for 1 hour >=20 > 3. Both schedules reference the same task and use the same task con= figurations thus they are measuring the same network measurement but at dif= ferent times. >=20 > 4. Intermediate results are sent to the collector periodically whil= e the schedule executes and then final results are sent once it completes. >=20 > 5. What in the results can be used to know which sets of results be= long to a single execution of the same schedule instance (example: Schedule= A)? This is my interpretation of LMAP; item #3 seems to address the need. > Item 1: The ietf-lmap-report path report/input/date is the time each resu= lt set was sent to the collector so that will be unique for each set of res= ults and so cannot be used. > Item 2: The report/input/task/name will be the same across the results fr= om the different schedules since they are both executing the same task so t= hat cannot be used. >=20 > Item 3: The report/input/task/row/start value would be the same across re= sults from a given schedule instance (ie. the Monday run) and yet unique ac= ross schedule instances (ie Mon vs Tues run) so it could be used. >=20 > > 6. What in the results can be used to know which sets of results be= long to all executions of the same schedule instance (example: Schedule A)? I think you can configure two different tasks with different tags and since= the tags are reported and the task name, you can distinguish things. Wheth= er this is practical or whether it should also be possible to set tags on a= n action is perhaps something to discuss. > Scenario #2: > While Item #3 above can address part of Scenario #1, it does not address = this additional scenario: >=20 > 1. Schedule A is performing a Performance Monitoring task (ex. TWAM= P) and so is configured for immediate and startup execution/events so it sh= ould always be running. >=20 > 2. The task is sending results to the collector periodically during= execution. >=20 > 3. The device hosting the MA is rebooted so the MA restarts the sch= edule/task execution. Thus the report/input/task/row/start value would be = different in the results sent after the restart. >=20 > 4. Since the same schedule/task definition is producing the results= before and after the MA restart, they logically belong to the same schedul= e execution. >=20 > 5. What can be used to group the results from before and after the = restart together? I think the mechanism to group measurements belonging logically together ta= gs. Looking at time stamps to group things is likely brittle. > Adding the schedule name to report/input/task would help but since the sc= hedule name can be reused, it does not infer a specific schedule instance. While having the schedule name may help in some situations, it won't in oth= ers. I think we should rather use tags that have no other meaning. This all= ows for example to rename schedules etc. In fact, I would prefer not to exp= ose the details how something got scheduled to the collector. It should not= matter much to the collector whether I use multiple schedules bound to the= same event with one action each or a single schedule bound to the event wi= th multiple concurrent actions. > Adding something like an 'initial schedule start' to report/input/task, w= here it is the date/time the schedule started the very first time (thus not= changing across MA restarts), seems to provide the needed association betw= een the result sets. This could be abstracted to a 'schedule id' since it = could alternatively be a unique id assigned to each schedule by the Control= ler. I would rather not put a requirement into the data model that an lmap imple= mentation has to manage persistent state. > While a custom value like this could be placed in report/input/task/tag o= r report/input/task/option I wanted to know if a common approach existed or= was planned. I think the tag was designed for this purpose, namely to be able to correla= te results that logically belong together. /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 Thu Jan 28 09:11:18 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 3C3C21A89F1 for ; Thu, 28 Jan 2016 09:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 kENN4U_OUwUR for ; Thu, 28 Jan 2016 09:11:08 -0800 (PST) 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 20BFA1A89F5 for ; Thu, 28 Jan 2016 09:11:02 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 07B6BF3E88D24; Thu, 28 Jan 2016 17:11:00 +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 u0SHB1WM014736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jan 2016 17:11:01 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 u0SHB02G004031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Jan 2016 17:11:00 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.82]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 28 Jan 2016 12:11:00 -0500 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP Result Correlation Thread-Index: AQHRWT1zdQZ+9uOJak2nQiJ7JPqUTZ8P9GBggAD43ICAACJXcA== Date: Thu, 28 Jan 2016 17:10:59 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A5B2139@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> <20160127140429.GB56525@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B1903@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160128082904.GA1957@elstar.local> In-Reply-To: <20160128082904.GA1957@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: "alissa@cooperw.in" , Ron Stana , "lmap@ietf.org" Subject: Re: [lmap] LMAP Result Correlation 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: Thu, 28 Jan 2016 17:11:15 -0000 Juergen, You are correct; I missed the point. Sorry I would simply add the correlation tag to the task-action as an option. The= se get reported in the report so you can use that. I wouldn't think we woul= d need to specify this as it is probably something SPs would control. BR, Tim -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Thursday, January 28, 2016 2:29 AM To: Carey, Timothy (Nokia - US) Cc: Ron Stana; alissa@cooperw.in; lmap@ietf.org Subject: Re: [lmap] LMAP Result Correlation Tim, how does this observation related to the discussion? The YANG model include= s the task name and the metric URIs in the report. This is inline with ma-r= eport-task-obj in the information model. The place where the report YANG data model differs from the information mod= el is the ma-report-task-cycle-id: the YANG data model allows for a set of = tags instead of a single cycle-id. /js On Wed, Jan 27, 2016 at 10:50:12PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > In the TR-069 data model we report the name of the task (not registry ent= ry) that was used in the report information. This is part of the ma-report= -task-obj.... >=20 > BR, > Tim > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 27, 2016 8:04 AM > To: Ron Stana > Cc: alissa@cooperw.in; lmap@ietf.org > Subject: Re: [lmap] LMAP Result Correlation >=20 > On Tue, Jan 12, 2016 at 05:02:36PM +0000, Ron Stana wrote: > > Alissa, LMAP Team, > > Regarding the September 2015 version of A Framework for Large-Scale Mea= surement of Broadband Performance [LMAP], I am trying to determine how mult= iple result sets for a given schedule instance/execution can be correlated. > > I think my questions are best illustrated using a couple scenarios: > > Scenario #1: > >=20 > > 1. Schedule A is configured to execute Monday@ 9:00am for 1 hour > >=20 > > 2. Schedule B is configured to execute Tuesday @ 9:00am for 1 hou= r > >=20 > > 3. Both schedules reference the same task and use the same task c= onfigurations thus they are measuring the same network measurement but at d= ifferent times. > >=20 > > 4. Intermediate results are sent to the collector periodically wh= ile the schedule executes and then final results are sent once it completes= . > >=20 > > 5. What in the results can be used to know which sets of results = belong to a single execution of the same schedule instance (example: Schedu= le A)? This is my interpretation of LMAP; item #3 seems to address the nee= d. > > Item 1: The ietf-lmap-report path report/input/date is the time each re= sult set was sent to the collector so that will be unique for each set of r= esults and so cannot be used. > > Item 2: The report/input/task/name will be the same across the results = from the different schedules since they are both executing the same task so= that cannot be used. > >=20 > > Item 3: The report/input/task/row/start value would be the same across = results from a given schedule instance (ie. the Monday run) and yet unique = across schedule instances (ie Mon vs Tues run) so it could be used. > >=20 > > > > 6. What in the results can be used to know which sets of results = belong to all executions of the same schedule instance (example: Schedule A= )? >=20 > I think you can configure two different tasks with different tags and sin= ce the tags are reported and the task name, you can distinguish things. Whe= ther this is practical or whether it should also be possible to set tags on= an action is perhaps something to discuss. >=20 > > Scenario #2: > > While Item #3 above can address part of Scenario #1, it does not addres= s this additional scenario: > >=20 > > 1. Schedule A is performing a Performance Monitoring task (ex. TW= AMP) and so is configured for immediate and startup execution/events so it = should always be running. > >=20 > > 2. The task is sending results to the collector periodically duri= ng execution. > >=20 > > 3. The device hosting the MA is rebooted so the MA restarts the s= chedule/task execution. Thus the report/input/task/row/start value would b= e different in the results sent after the restart. > >=20 > > 4. Since the same schedule/task definition is producing the resul= ts before and after the MA restart, they logically belong to the same sched= ule execution. > >=20 > > 5. What can be used to group the results from before and after th= e restart together? >=20 > I think the mechanism to group measurements belonging logically together = tags. Looking at time stamps to group things is likely brittle. >=20 > > Adding the schedule name to report/input/task would help but since the = schedule name can be reused, it does not infer a specific schedule instance= . >=20 > While having the schedule name may help in some situations, it won't in o= thers. I think we should rather use tags that have no other meaning. This a= llows for example to rename schedules etc. In fact, I would prefer not to e= xpose the details how something got scheduled to the collector. It should n= ot matter much to the collector whether I use multiple schedules bound to t= he same event with one action each or a single schedule bound to the event = with multiple concurrent actions. >=20 > > Adding something like an 'initial schedule start' to report/input/task,= where it is the date/time the schedule started the very first time (thus n= ot changing across MA restarts), seems to provide the needed association be= tween the result sets. This could be abstracted to a 'schedule id' since i= t could alternatively be a unique id assigned to each schedule by the Contr= oller. >=20 > I would rather not put a requirement into the data model that an lmap imp= lementation has to manage persistent state. >=20 > > While a custom value like this could be placed in report/input/task/tag= or report/input/task/option I wanted to know if a common approach existed = or was planned. >=20 > I think the tag was designed for this purpose, namely to be able to corre= late results that logically belong together. >=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 >=20 --=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 Sun Jan 31 12:36:23 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 8233A1A88B6 for ; Sun, 31 Jan 2016 12:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 CEpxTm6Af2lS for ; Sun, 31 Jan 2016 12:36:18 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 970A11B2C96 for ; Sun, 31 Jan 2016 12:36:17 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id l66so44878839wml.0 for ; Sun, 31 Jan 2016 12:36:17 -0800 (PST) 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 :cc:content-type; bh=m1TcXCr1EAqDihO9mQdO3fRMoKUemJtk/9iHmWCwmn8=; b=p1/YWFjT4ftNyysEk7GuRnh25WGr/ShXkeUp3zGJxSsZL2mvw19PPFbkhdZxECw5YK QsoKU0kpBsHXSxhcj4+bcT1ntMEDccQyaYBaDudD4fUe4lsOOX4Sjn0HcG8JK7qU0jMp ZivQbbOW8k8Bg94Z0CeS8r9tEvYqtEGVkbdY7nw5uPapkV4MeNH0psMmIfMmKUTfQqlL 1Wx+swwK2UU4DJSAWqNPmiOodFudM43VN+6G3XKMI7aV1o1yNOVfw02tGyiDeDgcyDcv 4ZXUnlm30qWQt2cOkKSj1AKqRp7FglXziDRPiwSfgcwnPGzQF4AAAL/EbfO37cTueFc8 zRxA== 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:cc:content-type; bh=m1TcXCr1EAqDihO9mQdO3fRMoKUemJtk/9iHmWCwmn8=; b=gfl8V8YuE4sq2CJ4CveJx1F9xqGkwBo1tb0SDWgchPHH1psnucGn9B3qq/z851YJlU A7HlHWJdiD6dgE/0Xrrlb9UNzVsAx88m0DyRfHCIMqBRh47UrjyG6f43wgw7rm6hbyds aDcLp9VdE+3vOCxoo5rEea6yoYyn0FsULfawZoTz94UNZnnbnToPPboVa+VHzV02L6qP F1BJxJVpek0GY8IQtPsj21LZyfNdVEKJVIqRIeyED5Rib7gqexVfuw7Va5Vl0CqQKyFJ UBU0Z0xYJLb41WowtBbU6OR/JJjJGieGRuMpJrEgZX7AqQIRCgzFaGY3C1xSp2AUWm4t 5y7w== X-Gm-Message-State: AG10YOQqcX1MGrMYjCrEfERWWHPxkPm802OQztbkfcFyX6NsvSLL7enOLvoJLmM3kr8d5xOoRNDApwgM2hUqMd+8 MIME-Version: 1.0 X-Received: by 10.194.82.199 with SMTP id k7mr21668199wjy.65.1454272575917; Sun, 31 Jan 2016 12:36:15 -0800 (PST) Received: by 10.28.232.78 with HTTP; Sun, 31 Jan 2016 12:36:15 -0800 (PST) In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A5B2139@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9CB9C91CE0CC0E42AA376AE9DE7A4DF17AC588F9@AMEXMB01.ds.jdsu.net> <20160127140429.GB56525@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B1903@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160128082904.GA1957@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A5B2139@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Sun, 31 Jan 2016 15:36:15 -0500 Message-ID: From: Ron Stana To: "Carey, Timothy (Nokia - US)" Content-Type: multipart/alternative; boundary=047d7bb04ece4b78fd052aa738d2 Archived-At: Cc: "alissa@cooperw.in" , Juergen Schoenwaelder , "lmap@ietf.org" Subject: Re: [lmap] LMAP Result Correlation 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: Sun, 31 Jan 2016 20:36:21 -0000 --047d7bb04ece4b78fd052aa738d2 Content-Type: text/plain; charset=UTF-8 Juergen, Tim, The intention is to be able to identify a set of results in the collector for each schedule. My understanding is the correlation tag would therefore need to be provided with the schedule rather than the task. This is my interpretation of LMAP, please correct me if it is incorrect: 1) tasks are predefined by the MA (example, ping, TWAMP,Y.1564, etc) 2) therefore, if a configuration cannot be sent to the MA containing a task with a task name that is unknown to the MA 3) the 'options' object sent within a task should be treated as a way to change the default parameters for the task from that point forward 4) a schedule is required to start an instance of a task 5) the 'options' object sent within the schedule is a way to override the task parameters for just that schedule Thus, if we have a ping test that as 2 parameters (target IP and number of pings), and a user wants to ping two destinations daily with the same number of pings, LMAP supports this scenario with the following configuration: 1) the 'options' for the Ping task could be used to set the number of pings. 2) the 'options' for Schedule A could set the target IP to y. This schedule will run daily. 3) the 'options' for Schedule B could set the target IP to z. This schedule will run daily at a time that does not conflict with Schedule A. Alternatively the Ping task would not have to be reconfigured at all if Schedules A and B additionally specified the number of pings in their 'options'. If this understanding is correct, then to retrieve the results from the collector for either Schedule A or Schedule B seems to require unique tag to be specified with the schedule instead of the task. The 'options' object for the schedule could be used, however it would be more symmetrical to allow a tag for the schedule since the value would be sent to the collector in the 'tag' object of the report. Ron On Thu, Jan 28, 2016 at 12:10 PM, Carey, Timothy (Nokia - US) < timothy.carey@nokia.com> wrote: > Juergen, > > You are correct; I missed the point. Sorry > > I would simply add the correlation tag to the task-action as an option. > These get reported in the report so you can use that. I wouldn't think we > would need to specify this as it is probably something SPs would control. > > BR, > Tim > > -----Original Message----- > From: EXT Juergen Schoenwaelder [mailto: > j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 28, 2016 2:29 AM > To: Carey, Timothy (Nokia - US) > Cc: Ron Stana; alissa@cooperw.in; lmap@ietf.org > Subject: Re: [lmap] LMAP Result Correlation > > Tim, > > how does this observation related to the discussion? The YANG model > includes the task name and the metric URIs in the report. This is inline > with ma-report-task-obj in the information model. > > The place where the report YANG data model differs from the information > model is the ma-report-task-cycle-id: the YANG data model allows for a set > of tags instead of a single cycle-id. > > /js > > On Wed, Jan 27, 2016 at 10:50:12PM +0000, Carey, Timothy (Nokia - US) > wrote: > > Juergen, > > > > In the TR-069 data model we report the name of the task (not registry > entry) that was used in the report information. This is part of the > ma-report-task-obj.... > > > > BR, > > Tim > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, January 27, 2016 8:04 AM > > To: Ron Stana > > Cc: alissa@cooperw.in; lmap@ietf.org > > Subject: Re: [lmap] LMAP Result Correlation > > > > On Tue, Jan 12, 2016 at 05:02:36PM +0000, Ron Stana wrote: > > > Alissa, LMAP Team, > > > Regarding the September 2015 version of A Framework for Large-Scale > Measurement of Broadband Performance [LMAP], I am trying to determine how > multiple result sets for a given schedule instance/execution can be > correlated. > > > I think my questions are best illustrated using a couple scenarios: > > > Scenario #1: > > > > > > 1. Schedule A is configured to execute Monday@ 9:00am for 1 hour > > > > > > 2. Schedule B is configured to execute Tuesday @ 9:00am for 1 > hour > > > > > > 3. Both schedules reference the same task and use the same task > configurations thus they are measuring the same network measurement but at > different times. > > > > > > 4. Intermediate results are sent to the collector periodically > while the schedule executes and then final results are sent once it > completes. > > > > > > 5. What in the results can be used to know which sets of results > belong to a single execution of the same schedule instance (example: > Schedule A)? This is my interpretation of LMAP; item #3 seems to address > the need. > > > Item 1: The ietf-lmap-report path report/input/date is the time each > result set was sent to the collector so that will be unique for each set of > results and so cannot be used. > > > Item 2: The report/input/task/name will be the same across the results > from the different schedules since they are both executing the same task so > that cannot be used. > > > > > > Item 3: The report/input/task/row/start value would be the same across > results from a given schedule instance (ie. the Monday run) and yet unique > across schedule instances (ie Mon vs Tues run) so it could be used. > > > > > > > > > 6. What in the results can be used to know which sets of results > belong to all executions of the same schedule instance (example: Schedule > A)? > > > > I think you can configure two different tasks with different tags and > since the tags are reported and the task name, you can distinguish things. > Whether this is practical or whether it should also be possible to set tags > on an action is perhaps something to discuss. > > > > > Scenario #2: > > > While Item #3 above can address part of Scenario #1, it does not > address this additional scenario: > > > > > > 1. Schedule A is performing a Performance Monitoring task (ex. > TWAMP) and so is configured for immediate and startup execution/events so > it should always be running. > > > > > > 2. The task is sending results to the collector periodically > during execution. > > > > > > 3. The device hosting the MA is rebooted so the MA restarts the > schedule/task execution. Thus the report/input/task/row/start value would > be different in the results sent after the restart. > > > > > > 4. Since the same schedule/task definition is producing the > results before and after the MA restart, they logically belong to the same > schedule execution. > > > > > > 5. What can be used to group the results from before and after > the restart together? > > > > I think the mechanism to group measurements belonging logically together > tags. Looking at time stamps to group things is likely brittle. > > > > > Adding the schedule name to report/input/task would help but since the > schedule name can be reused, it does not infer a specific schedule instance. > > > > While having the schedule name may help in some situations, it won't in > others. I think we should rather use tags that have no other meaning. This > allows for example to rename schedules etc. In fact, I would prefer not to > expose the details how something got scheduled to the collector. It should > not matter much to the collector whether I use multiple schedules bound to > the same event with one action each or a single schedule bound to the event > with multiple concurrent actions. > > > > > Adding something like an 'initial schedule start' to > report/input/task, where it is the date/time the schedule started the very > first time (thus not changing across MA restarts), seems to provide the > needed association between the result sets. This could be abstracted to a > 'schedule id' since it could alternatively be a unique id assigned to each > schedule by the Controller. > > > > I would rather not put a requirement into the data model that an lmap > implementation has to manage persistent state. > > > > > While a custom value like this could be placed in > report/input/task/tag or report/input/task/option I wanted to know if a > common approach existed or was planned. > > > > I think the tag was designed for this purpose, namely to be able to > correlate results that logically belong together. > > > > /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 > --047d7bb04ece4b78fd052aa738d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen, Tim,
<= div>
The intention is to be able to identify a set of results i= n the collector for each schedule. My understanding is the correlation tag = would therefore need to be provided with the schedule rather than the task.=

This is my interpretation of LMAP, please co= rrect me if it is incorrect:
1) tasks are predefined by the MA (example, ping, TWAMP,Y.1564, etc)
2) therefore, if a configur= ation cannot be sent to the MA containing a task with a task name that is u= nknown to the MA
3) the &= #39;options' object sent within a task should be treated as a way to ch= ange the default parameters for the task from that point forward=C2=A0
4) a schedule is required to = start an instance of a task
5) the 'options' object sent within the schedule is a way to ove= rride the task parameters for just that schedule

Thus, if we have a ping test that as 2 parameters (target IP and number= of pings), and a user wants to ping two destinations daily with the same n= umber of pings, LMAP supports this scenario with the following configuratio= n:
1) the 'options= 9; for the Ping task could be used to set the number of pings.
=
2) the 'options' for Schedule= A could set the target IP to y.=C2=A0 This schedule will run daily.=
3) the 'options' for Sc= hedule B could set the target IP to z. =C2=A0This schedule will run daily at a time that does not conflict wit= h Schedule A.

Alternatively the Ping task w= ould not have to be reconfigured at all if Schedules A and B additionally s= pecified the number of pings in their 'options'.

If this understanding is correct, then to retrieve the results from = the collector for either Schedule A or Schedule B seems to require unique t= ag to be specified with the schedule instead of the task.=C2=A0 The 'op= tions' object for the schedule could be used, however it would be more = symmetrical to allow a tag for the schedule since the value would be sent t= o the collector in the 'tag' object of the report.

Ron

On Thu, Jan 28, 2016 at 12:10 PM, Carey, Timothy (Nokia - US) <timothy.carey@nokia.com> wrote:
Juergen,

You are correct; I missed the point. Sorry

I would simply add the correlation tag to the task-action as an option. The= se get reported in the report so you can use that. I wouldn't think we = would need to specify this as it is probably something SPs would control.
BR,
Tim

-----Original Message-----
From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Thursday, January 28, 2016 2:29 AM
To: Carey, Timothy (Nokia - US)
Cc: Ron Stana; alissa@cooperw.in; = lmap@ietf.org
Subject: Re: [lmap] LMAP Result Correlation

Tim,

how does this observation related to the discussion? The YANG model include= s the task name and the metric URIs in the report. This is inline with ma-r= eport-task-obj in the information model.

The place where the report YANG data model differs from the information mod= el is the ma-report-task-cycle-id: the YANG data model allows for a set of = tags instead of a single cycle-id.

/js

On Wed, Jan 27, 2016 at 10:50:12PM +0000, Carey, Timothy (Nokia - US) wrote= :
> Juergen,
>
> In the TR-069 data model we report the name of the task (not registry = entry) that was used in the report information.=C2=A0 This is part of the m= a-report-task-obj....
>
> BR,
> Tim
> -----Original Message-----
> From: Juergen Schoenwaelder
> [mailto:j.scho= enwaelder@jacobs-university.de]
> Sent: Wednesday, January 27, 2016 8:04 AM
> To: Ron Stana
> Cc: alissa@cooperw.in; lmap@ietf.org
> Subject: Re: [lmap] LMAP Result Correlation
>
> On Tue, Jan 12, 2016 at 05:02:36PM +0000, Ron Stana wrote:
> > Alissa, LMAP Team,
> > Regarding the September 2015 version of A Framework for Large-Sca= le Measurement of Broadband Performance [LMAP], I am trying to determine ho= w multiple result sets for a given schedule instance/execution can be corre= lated.
> > I think my questions are best illustrated using a couple scenario= s:
> > Scenario #1:
> >
> > 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0Schedule A is configured to execute = Monday@ 9:00am for 1 hour
> >
> > 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0Schedule B is configured to execute = Tuesday @ 9:00am for 1 hour
> >
> > 3.=C2=A0 =C2=A0 =C2=A0 =C2=A0Both schedules reference the same ta= sk and use the same task configurations thus they are measuring the same ne= twork measurement but at different times.
> >
> > 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0Intermediate results are sent to the= collector periodically while the schedule executes and then final results = are sent once it completes.
> >
> > 5.=C2=A0 =C2=A0 =C2=A0 =C2=A0What in the results can be used to k= now which sets of results belong to a single execution of the same schedule= instance (example: Schedule A)?=C2=A0 This is my interpretation of LMAP; i= tem #3 seems to address the need.
> > Item 1: The ietf-lmap-report path report/input/date is the time e= ach result set was sent to the collector so that will be unique for each se= t of results and so cannot be used.
> > Item 2: The report/input/task/name will be the same across the re= sults from the different schedules since they are both executing the same t= ask so that cannot be used.
> >
> > Item 3: The report/input/task/row/start value would be the same a= cross results from a given schedule instance (ie. the Monday run) and yet u= nique across schedule instances (ie Mon vs Tues run) so it could be used. > >
> >
> > 6.=C2=A0 =C2=A0 =C2=A0 =C2=A0What in the results can be used to k= now which sets of results belong to all executions of the same schedule ins= tance (example: Schedule A)?
>
> I think you can configure two different tasks with different tags and = since the tags are reported and the task name, you can distinguish things. = Whether this is practical or whether it should also be possible to set tags= on an action is perhaps something to discuss.
>
> > Scenario #2:
> > While Item #3 above can address part of Scenario #1, it does not = address this additional scenario:
> >
> > 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0Schedule A is performing a Performan= ce Monitoring task (ex. TWAMP) and so is configured for immediate and start= up execution/events so it should always be running.
> >
> > 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0The task is sending results to the c= ollector periodically during execution.
> >
> > 3.=C2=A0 =C2=A0 =C2=A0 =C2=A0The device hosting the MA is reboote= d so the MA restarts the schedule/task execution.=C2=A0 Thus the report/inp= ut/task/row/start value would be different in the results sent after the re= start.
> >
> > 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0Since the same schedule/task definit= ion is producing the results before and after the MA restart, they logicall= y belong to the same schedule execution.
> >
> > 5.=C2=A0 =C2=A0 =C2=A0 =C2=A0What can be used to group the result= s from before and after the restart together?
>
> I think the mechanism to group measurements belonging logically togeth= er tags. Looking at time stamps to group things is likely brittle.
>
> > Adding the schedule name to report/input/task would help but sinc= e the schedule name can be reused, it does not infer a specific schedule in= stance.
>
> While having the schedule name may help in some situations, it won'= ;t in others. I think we should rather use tags that have no other meaning.= This allows for example to rename schedules etc. In fact, I would prefer n= ot to expose the details how something got scheduled to the collector. It s= hould not matter much to the collector whether I use multiple schedules bou= nd to the same event with one action each or a single schedule bound to the= event with multiple concurrent actions.
>
> > Adding something like an 'initial schedule start' to repo= rt/input/task, where it is the date/time the schedule started the very firs= t time (thus not changing across MA restarts), seems to provide the needed = association between the result sets.=C2=A0 This could be abstracted to a &#= 39;schedule id' since it could alternatively be a unique id assigned to= each schedule by the Controller.
>
> I would rather not put a requirement into the data model that an lmap = implementation has to manage persistent state.
>
> > While a custom value like this could be placed in report/input/ta= sk/tag or report/input/task/option I wanted to know if a common approach ex= isted or was planned.
>
> I think the tag was designed for this purpose, namely to be able to co= rrelate results that logically belong together.
>
> /js
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 287= 59 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>
>
>

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

--047d7bb04ece4b78fd052aa738d2--