From philip.eardley@bt.com Thu May 2 02:52:12 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9321F89B2 for ; Thu, 2 May 2013 02:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UAsLhTA2uby for ; Thu, 2 May 2013 02:52:08 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 10DEB21F9974 for ; Thu, 2 May 2013 02:52:07 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 2 May 2013 10:52:06 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.234]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Thu, 2 May 2013 10:52:05 +0100 From: To: Date: Thu, 2 May 2013 10:52:04 +0100 Thread-Topic: New Version Notification for draft-eardley-lmap-terminology-01.txt Thread-Index: Ac5HEKjHMqbeb2YYRxCk+UK+Avdb1wACdm3A Message-ID: <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> In-Reply-To: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 09:52:12 -0000 SSB1cGRhdGVkIHRoZSBkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lYXJk bGV5LWxtYXAtdGVybWlub2xvZ3kNClRoYW5rLXlvdSBmb3IgYWxsIHRoZSBjb21tZW50cyENCg0K KHRoZSBkcmFmdCBpcyBhIHBvc3NpYmxlIHN0YXJ0aW5nIHBvaW50IGZvciB0ZXJtaW5vbG9neSBm b3IgdGhlIHByb3NwZWN0aXZlIGxtYXAgd2cpDQoNCkJlc3Qgd2lzaGVzDQpwaGlsDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogMDIgTWF5IDIwMTMgMDk6NDAN ClRvOiBBbCBNb3J0b247IEVhcmRsZXksUEwsUGhpbGlwLFRVQjggUjsgQnVyYnJpZGdlLFQsVHJl dm9yLFRVQjggUjsgQWwgQy5Nb3J0b247IE1hcmNlbG8gQmFnbnVsbw0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1lYXJkbGV5LWxtYXAtdGVybWlub2xvZ3ktMDEu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWVhcmRsZXktbG1hcC10ZXJtaW5v bG9neS0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGhpbGlwIEVh cmRsZXkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRy YWZ0LWVhcmRsZXktbG1hcC10ZXJtaW5vbG9neQ0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgVGVy bWlub2xvZ3kgZm9yIExhcmdlIE1lQXN1cmVtZW50IFBsYXRmb3JtcyAoTE1BUCkNCkNyZWF0aW9u IGRhdGU6CSAyMDEzLTA1LTAyDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJl ciBvZiBwYWdlczogMTANClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtZWFyZGxleS1sbWFwLXRlcm1pbm9sb2d5LTAxLnR4dA0KU3RhdHVz OiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWVhcmRsZXkt bG1hcC10ZXJtaW5vbG9neQ0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1lYXJkbGV5LWxtYXAtdGVybWlub2xvZ3ktMDENCkRpZmY6ICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZWFyZGxleS1sbWFwLXRlcm1p bm9sb2d5LTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudHMgZGVmaW5lcyB0ZXJtaW5v bG9neSBmb3IgTGFyZ2UgU2NhbGUgTWVhc3VyZW1lbnQNCiAgIFBsYXRmb3Jtcy4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From jerome.benoit@grenouille.com Thu May 2 07:14:23 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF5921F8A4E for ; Thu, 2 May 2013 07:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk51h8KrBrTg for ; Thu, 2 May 2013 07:14:19 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3C66A21F84F5 for ; Thu, 2 May 2013 07:14:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id E83967F21E for ; Thu, 2 May 2013 16:14:17 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3JBU2Sb7Ses for ; Thu, 2 May 2013 16:14:08 +0200 (CEST) Date: Thu, 2 May 2013 16:14:07 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: lmap@ietf.org Message-ID: <20130502161407.7e71a328@nemesis.grenouille.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/=/g+wEgTfasAEG_hQFIhXgw"; protocol="application/pgp-signature" Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:14:23 -0000 --Sig_/=/g+wEgTfasAEG_hQFIhXgw Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, 11 Apr 2013 20:22:55 +0000 in <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.co= m>, STARK, BARBARA H "STARK, BARBARA H" wrote: > While I have seen statements proclaiming the value of 3rd party measureme= nt systems (and, BTW, I agree that such systems are valuable) I don't recal= l having seen requests for helping to architect such systems. People who ha= ve put such systems together seem to be quite happy with their systems. How= ever, they may benefit from ippm recommendations and efforts. They may also= benefit from mappings of ippm registry elements into certain IETF protocol= models (such as SNMP MIBs, netconf data model, or ipfix data model). They = may benefit from something that allows the ISP to provide Servcie Attribute= s to MAs inside the end user network. And they may benefit from privacy rec= ommendations. The people that would like to help architect a measurement that permit also 3rd party to do measurement and to dig results in a anonymized =20 fashion are unfortunately currently very busy with other stuff (personal issues for my case, but who care ?). That said, it's still on my TODO list to review and comment the current RFCs written here and propose some changes in that direction. It will never be too late to amend a RFC, even if it's already promoted as a gold standard. I'll come back on the LMAP's RFCs when I will be able to do so.=20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/=/g+wEgTfasAEG_hQFIhXgw Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGCdK8ACgkQ+qDLUJ/pFh3OXwCgj8rhNaOg7JKG/QgBu3T4UeaI fHYAnie3AgiUMZ7zPkYD8UFiDTKEF4vt =++5s -----END PGP SIGNATURE----- --Sig_/=/g+wEgTfasAEG_hQFIhXgw-- From jerome.benoit@grenouille.com Thu May 2 08:06:53 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4596621F8EB9 for ; Thu, 2 May 2013 08:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqLvrt7s51jk for ; Thu, 2 May 2013 08:06:49 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 287EE21F8E74 for ; Thu, 2 May 2013 08:06:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id BB2C17F731 for ; Thu, 2 May 2013 17:06:47 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NxMNqStyLxt for ; Thu, 2 May 2013 17:06:36 +0200 (CEST) Date: Thu, 2 May 2013 17:06:35 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: lmap@ietf.org Message-ID: <20130502170635.714505d5@nemesis.grenouille.com> In-Reply-To: <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/vHA2Bdbl1SOgTIDOzEya3Jq"; protocol="application/pgp-signature" Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:06:53 -0000 --Sig_/vHA2Bdbl1SOgTIDOzEya3Jq Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, 2 May 2013 10:52:04 +0100 in <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.n= et>, philip.eardley@bt.com wrote: > I updated the draft http://tools.ietf.org/html/draft-eardley-lmap-termino= logy > Thank-you for all the comments! 2. Summary I dislike the terminology "Measurement Peer", I prefer "Measurement Landmarks". The measurement agent with talk to different peer (MC, etc.), only one or several of these peer(s) will be used to target the measurement task. =20 3. LMAP Terminology=20 "Bootstrap Protocol: A protocol that initialises a Measurement Agent ^ initialize ? with the information necessary to talk to a Controller." Why do you use "function" everywhere ? It's a functionality.=20 Measurement Method vs. Measurement Task vs. Passive Measurement Method I tend to disagree in the differentiation unless you explain what is really the difference. When people design measurement (active or passive), they build a complete methodology that will differ in term requirements but the output will be metrics if case of active measurement and for passive measurement ... it really depend :=20 Use case one : I choose to not put the TCP session inter-packets delay calculation on the measurement agent, I just extract the timestamp and sequence number of each packets in one TCP session and sent them.=20 Use case two : To bootstrap a passive measurement that will detect network anomalies, I need to build a "fingerprint" database of network behaviours, to do so, I need to send something that will look like a netflow data model to build such a fingerprint database. This use case is more a bootstrapping measurement method to permit to build a passive measurement method.=20 What matter here, it's the overall repartition of the intelligence between each logical component of the measurement system. Passive measurement method will need to put more intelligence in the MA. =20 3.1 Other potentially useful terminology Measurement Parameter and Environmental Constraint Same as before : it's in the measurement method if it's needed. I think you should create a distinct paragraph for the measurement method. =20 4. Commentary and notes "By definition a Measurement Peer does not interact with a Controller or Collector"=20 Not sure it's a wise idea : the measurement method will have to ensure that the peer or landmark is for example not overloaded, or correctly on time, or just alive. Why not saying that the measurement controller is also tracking some states of measurement peer or landmark and will then either postpone some future measurement to this landmark ?=20 If you choose to not do so, measurement method will need mix their primary functionality : do measurement and also check that should be part of the measurement method : can I do the measurement with the peer or landmark ?=20 Cheers. =20 =20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/vHA2Bdbl1SOgTIDOzEya3Jq Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGCgPsACgkQ+qDLUJ/pFh2ktgCdEocAbFIaJYvq6w705Hmr01nI v+gAoN8SxjCFhHKbyRIhKBCCXy7/tWia =QKOk -----END PGP SIGNATURE----- --Sig_/vHA2Bdbl1SOgTIDOzEya3Jq-- From jerome.benoit@grenouille.com Thu May 2 08:50:50 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1C421F8FFC for ; Thu, 2 May 2013 08:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZG9ZYOkRd4y for ; Thu, 2 May 2013 08:50:45 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id A492E21F8FF5 for ; Thu, 2 May 2013 08:50:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 75EFD7F636 for ; Thu, 2 May 2013 17:50:42 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZZvlTSEZGiH for ; Thu, 2 May 2013 17:50:30 +0200 (CEST) Date: Thu, 2 May 2013 17:50:28 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: lmap@ietf.org Message-ID: <20130502175028.7da2872f@nemesis.grenouille.com> In-Reply-To: <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/og+VhJwflC2hf21k=qHJ.vu"; protocol="application/pgp-signature" Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:50:50 -0000 --Sig_/og+VhJwflC2hf21k=qHJ.vu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, 19 Apr 2013 11:29:40 +0100 in <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.n= et>, philip.eardley@bt.com wrote: >=20 > > Question 1. Use cases > > Do we agree that we want to focus on the Internet Service Provider and > > the End User Network Diagnostics use cases for now? As a phase 2, we > > could focus on the 3rd party use case: multi-provider, regulator, over > > the top > > Question: in the End User Network Diagnostics use case, I'm unclear if > > the user initiated measurement is included? >=20 > Here's a proposed answer:- >=20 > In order to simplify the security and policy considerations, we propose t= hat LMAP phase 1 should make the assumption that the measurement system is = under the control of a single organisation. 'Measurement system' refers to = the Measurement Agent, Controller and Collector. There is likely to be inte= rest in LMAP phase 2 in scenarios where the measurement system is not under= the control of a single organisation. >=20 > Note that the Measurement Peer may be under another organisation's contro= l (for example, the Measurement Peer might be in example.com, with the Meas= urement Task to download example.com's homepage or to send a request to its= DNS server). However, this doesn't affect LMAP's 'single organisation' ass= umption since the job of defining Measurement Tasks is left to IPPM. I'm not sure the single org approach will solve the lack of coherency between each logical component inside the measurement system. inter or intra do not matter (I still disagree on the single org that will be responsible of the system but I understand that it's only a phase) : the measurement system need to keep track of the relevant state, characteristics and capabilities of each logical component. It's a mandatory component to do CAC.=20 Use case : 10 min of UDP stream to a landmark run to a single landmark. Can the landmark handle the network load ? Can the MA infer cross-traffic (via UPnP if runt behind the CPE, via an other measurement method) ? =20 >=20 > Discussion has revealed one new capability that may be required. Before a= Measurement Task actually runs, the Measurement Agent may need to check th= at the Peer can carry out the Task. If one considers this as an initial sta= ge of the Task, then it would be something for IPPM to define. The load is just one aspect of the problem. The real problem is that some measurement method need to know about the states in the measurement system : do I have enough landmark ? do I have enough MA (free slot) ? do I have enough residual bandwidth ?=20 Before thinking about on how to implement the decision tree that will trigger a measurement task, the first task it the have a component that will permit to build the decision tree : the states, characteristics and capabilities tracker of each logical component.=20 Regards, =20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/og+VhJwflC2hf21k=qHJ.vu Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGCi0QACgkQ+qDLUJ/pFh3TywCeNuF9YdO/q1FIJCC8xIImSxLS tSkAoL/jIX2mmZG+BRmRrViVpFE7VZTC =VmSS -----END PGP SIGNATURE----- --Sig_/og+VhJwflC2hf21k=qHJ.vu-- From dengguangqing@cnnic.cn Thu May 2 18:36:27 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4948921F863B for ; Thu, 2 May 2013 18:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.722 X-Spam-Level: * X-Spam-Status: No, score=1.722 tagged_above=-999 required=5 tests=[AWL=2.469, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27dSkODCEXtf for ; Thu, 2 May 2013 18:36:23 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id BD3BF21F8610 for ; Thu, 2 May 2013 18:36:20 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 03 May 2013 09:36:10 +0800 Date: Fri, 3 May 2013 09:36:08 +0800 From: "Guangqing Deng" To: =?utf-8?B?SsOpcsO0bWUgQmVub2l0?= References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com>, <20130502161407.7e71a328@nemesis.grenouille.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201305030936078772791@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart503215128047_=----" Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 01:36:27 -0000 This is a multi-part message in MIME format. ------=_001_NextPart503215128047_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SU1PLCBpZiB0aGUgd29yayBvZiBhcmNoaXRlY3RpbmcgYSAzcmQgcGFydHkgbWVhc3VyZW1lbnQg c3lzdGVtIGlzIHNlcGFyYXRlZCBpbnRvIHNvbWUgcGFydHMgYnkgc29tZW9uZSB3aG8gaGFzIGV4 cGVydGlzZSBvbiB0aGF0LCBpdCBpcyBjb252ZW5pZW50IGZvciB0aG9zZSB3aG8gaGF2ZSBpbnRl cmVzdCBvbiB0aGlzIHdvcmsgdG8gam9pbiBpbiB0aGlzIGFjdGl2aXR5LCBwaWNrIGEgcGllY2Ug b2Ygd29yayBhbmQgYWNoaWV2ZSBleHBlY3RlZCByZXN1bHRzIHdpdGhpbiBhIGxpbWl0ZWQgcGVy aW9kIG9mIHRpbWUuDQoNCg0KDQoNCkd1YW5ncWluZyBEZW5nDQpDTk5JQyANCg0KRnJvbTogSsOp csO0bWUgQmVub2l0DQpEYXRlOiAyMDEzLTA1LTAyIDIyOjE0DQpUbzogbG1hcA0KU3ViamVjdDog UmU6IFtsbWFwXSBMTUFQOiBzaXR1YXRpb246IFExLVVzZSBDYXNlcw0KT24gVGh1LCAxMSBBcHIg MjAxMyAyMDoyMjo1NSArMDAwMCBpbg0KPDJEMDlENjFEREZBNzNENEM4ODQ4MDVDQzc4NjVFNjEx MzAyQTNFMTlAR0FBTFBBMU1TR1VTUjlMLklUU2VydmljZXMuc2JjLmNvbT4sDQpTVEFSSywgQkFS QkFSQSBIICJTVEFSSywgQkFSQkFSQSBIIiA8YnM3NjUyQGF0dC5jb20+IHdyb3RlOg0KDQoNCj4g V2hpbGUgSSBoYXZlIHNlZW4gc3RhdGVtZW50cyBwcm9jbGFpbWluZyB0aGUgdmFsdWUgb2YgM3Jk IHBhcnR5IG1lYXN1cmVtZW50IHN5c3RlbXMgKGFuZCwgQlRXLCBJIGFncmVlIHRoYXQgc3VjaCBz eXN0ZW1zIGFyZSB2YWx1YWJsZSkgSSBkb24ndCByZWNhbGwgaGF2aW5nIHNlZW4gcmVxdWVzdHMg Zm9yIGhlbHBpbmcgdG8gYXJjaGl0ZWN0IHN1Y2ggc3lzdGVtcy4gUGVvcGxlIHdobyBoYXZlIHB1 dCBzdWNoIHN5c3RlbXMgdG9nZXRoZXIgc2VlbSB0byBiZSBxdWl0ZSBoYXBweSB3aXRoIHRoZWly IHN5c3RlbXMuIEhvd2V2ZXIsIHRoZXkgbWF5IGJlbmVmaXQgZnJvbSBpcHBtIHJlY29tbWVuZGF0 aW9ucyBhbmQgZWZmb3J0cy4gVGhleSBtYXkgYWxzbyBiZW5lZml0IGZyb20gbWFwcGluZ3Mgb2Yg aXBwbSByZWdpc3RyeSBlbGVtZW50cyBpbnRvIGNlcnRhaW4gSUVURiBwcm90b2NvbCBtb2RlbHMg KHN1Y2ggYXMgU05NUCBNSUJzLCBuZXRjb25mIGRhdGEgbW9kZWwsIG9yIGlwZml4IGRhdGEgbW9k ZWwpLiBUaGV5IG1heSBiZW5lZml0IGZyb20gc29tZXRoaW5nIHRoYXQgYWxsb3dzIHRoZSBJU1Ag dG8gcHJvdmlkZSBTZXJ2Y2llIEF0dHJpYnV0ZXMgdG8gTUFzIGluc2lkZSB0aGUgZW5kIHVzZXIg bmV0d29yay4gQW5kIHRoZXkgbWF5IGJlbmVmaXQgZnJvbSBwcml2YWN5IHJlY29tbWVuZGF0aW9u cy4NCg0KVGhlIHBlb3BsZSB0aGF0IHdvdWxkIGxpa2UgdG8gaGVscCBhcmNoaXRlY3QgYSBtZWFz dXJlbWVudCB0aGF0IHBlcm1pdA0KYWxzbyAzcmQgcGFydHkgdG8gZG8gbWVhc3VyZW1lbnQgYW5k IHRvIGRpZyByZXN1bHRzIGluIGEgYW5vbnltaXplZCAgDQpmYXNoaW9uIGFyZSB1bmZvcnR1bmF0 ZWx5IGN1cnJlbnRseSB2ZXJ5IGJ1c3kgd2l0aCBvdGhlciBzdHVmZg0KKHBlcnNvbmFsIGlzc3Vl cyBmb3IgbXkgY2FzZSwgYnV0IHdobyBjYXJlID8pLiBUaGF0IHNhaWQsIGl0J3Mgc3RpbGwgb24N Cm15IFRPRE8gbGlzdCB0byByZXZpZXcgYW5kIGNvbW1lbnQgdGhlIGN1cnJlbnQgUkZDcyB3cml0 dGVuIGhlcmUgYW5kDQpwcm9wb3NlIHNvbWUgY2hhbmdlcyBpbiB0aGF0IGRpcmVjdGlvbi4gSXQg d2lsbCBuZXZlciBiZSB0b28NCmxhdGUgdG8gYW1lbmQgYSBSRkMsIGV2ZW4gaWYgaXQncyBhbHJl YWR5IHByb21vdGVkIGFzIGEgZ29sZA0Kc3RhbmRhcmQuIEknbGwgY29tZSBiYWNrIG9uIHRoZSBM TUFQJ3MgUkZDcyB3aGVuIEkgd2lsbCBiZQ0KYWJsZSB0byBkbyBzby4gDQoNCi0tIA0KSsOpcsO0 bWUgQmVub2l0IGFrYSBmcmFnZ2xlDQpMYSBNw6l0w6lvIGR1IE5ldCAtIGh0dHA6Ly9ncmVub3Vp bGxlLmNvbQ0KT3BlblBHUCBLZXkgSUQgOiA5RkU5MTYxRA0KS2V5IGZpbmdlcnByaW50IDogOUNB NCAwMjQ5IEFGNTcgQTM1QiAzNEIzIEFDMTUgRkFBMCBDQjUwIDlGRTkgMTYxRA0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxtYXAgbWFpbGlu ZyBsaXN0DQpsbWFwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2xtYXA= ------=_001_NextPart503215128047_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF

IMO, if the work of architecting a 3rd<= /SUP>=20 party measurement system is separated into some parts by someone who has=20 expertise on that, it is convenient for those who have interest on this wo= rk to=20 join in this activity, pick a piece of work and achieve expected results w= ithin=20 a limited period of time.

 
Guangqing=20 Deng
CNNIC 
 
Date: 2013-05-02 22:14
To: lmap
Subject: Re: [lmap] LMAP: situation: Q1-Use=20 Cases
On Thu, 11 Apr 2013 20:22:55 +0000 = ;in
<2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServic= es.sbc.com>,
STARK, BARBARA H "STARK, BARBARA H" <= ;bs7652@att.com> wrote:
 
 
> While I have seen statements procl= aiming the value of 3rd party measurement&nb= sp;systems (and, BTW, I agree that such = ;systems are valuable) I don't recall having=  seen requests for helping to architect = ;such systems. People who have put such = ;systems together seem to be quite happy&nbs= p;with their systems. However, they may bene= fit from ippm recommendations and efforts. T= hey may also benefit from mappings of i= ppm registry elements into certain IETF prot= ocol models (such as SNMP MIBs, netconf = ;data model, or ipfix data model). They = ;may benefit from something that allows the&= nbsp;ISP to provide Servcie Attributes to MA= s inside the end user network. And they=  may benefit from privacy recommendations.
 
The people that would like to help = ;architect a measurement that permit
also 3rd party to do measurement and&nb= sp;to dig results in a anonymized  
fashion are unfortunately currently very bus= y with other stuff
(personal issues for my case, but who&n= bsp;care ?). That said, it's still on
my TODO list to review and comment = ;the current RFCs written here and
propose some changes in that direction. = ;It will never be too
late to amend a RFC, even if it's&= nbsp;already promoted as a gold
standard. I'll come back on the LMAP's&= nbsp;RFCs when I will be
able to do so. 
 
-- 
J=C3=A9r=C3=B4me Benoit aka fraggle
La M=C3=A9t=C3=A9o du Net - http://grenouill= e.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B&n= bsp;34B3 AC15 FAA0 CB50 9FE9 161D
 
 
 
_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap
 
------=_001_NextPart503215128047_=------ From philip.eardley@bt.com Fri May 3 01:23:59 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABC821F8506 for ; Fri, 3 May 2013 01:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENRHhTbL5KCK for ; Fri, 3 May 2013 01:23:55 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 470C021F9434 for ; Fri, 3 May 2013 01:23:51 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 3 May 2013 09:23:49 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.241]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 3 May 2013 09:23:48 +0100 From: To: , Date: Fri, 3 May 2013 09:23:47 +0100 Thread-Topic: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt Thread-Index: Ac5HRrHYeRz5FnkYSSS9NkpR7TGhDQAi34NQ Message-ID: <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net> References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> <20130502170635.714505d5@nemesis.grenouille.com> In-Reply-To: <20130502170635.714505d5@nemesis.grenouille.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 08:23:59 -0000 Jerome Thanks for the comments In-line phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > J=E9r=F4me Benoit > Sent: 02 May 2013 16:07 > To: lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-eardley- > lmap-terminology-01.txt >=20 > On Thu, 2 May 2013 10:52:04 +0100 in > <9510D26531EF184D9017DF24659BB87F345B116163@EMV65- > UKRD.domain1.systemhost.net>, > philip.eardley@bt.com wrote: >=20 > > I updated the draft > > http://tools.ietf.org/html/draft-eardley-lmap-terminology > > Thank-you for all the comments! >=20 > 2. Summary >=20 > I dislike the terminology "Measurement Peer", I prefer "Measurement > Landmarks". The measurement agent with talk to different peer (MC, > etc.), only one or several of these peer(s) will be used to target the > measurement task. >=20 Measurement Peer vs Landmark - I'm easy either way. >=20 > 3. LMAP Terminology >=20 > "Bootstrap Protocol: A protocol that initialises a Measurement Agent > ^ initialize ? > with the information necessary to talk to a Controller." Initialise vs initialize. For several words -ise and -ize are alternative s= pellings in UK English (-ise is somewhat more common) >=20 > Why do you use "function" everywhere ? It's a functionality. >=20 I don't think there's a clear difference between function and functionality= . Functionality roughly seems to mean a set of functions. At least function= is less typing! > Measurement Method vs. Measurement Task vs. Passive Measurement Method >=20 > I tend to disagree in the differentiation unless you explain what is > really the difference. When people design measurement (active or > passive), they build a complete methodology that will differ in term > requirements but the output will be metrics if case of active > measurement and for passive measurement ... it really depend : >=20 > Use case one : I choose to not put the TCP session inter-packets delay > calculation on the measurement agent, I just extract the timestamp and > sequence number of each packets in one TCP session and sent them. I'd say that the Measurement Method (which is Passive) is to "extract the t= imestamp and sequence number of every packet in a TCP session", whilst the = associated (Passive) Measurement Task would be something like "for the TCP = session from the source 192.0.2.0 destined for 198.51.100.0 and starting at= UTC 13:01 and 58.6 seconds on 2013-06-15, then extract the timestamp and s= equence number of every packet in the TCP session" > Use case two : To bootstrap a passive measurement that will detect > network anomalies, I need to build a "fingerprint" database of network > behaviours, to do so, I need to send something that will look like a > netflow data model to build such a fingerprint database. This use case > is more a bootstrapping measurement method to permit to build a passive > measurement method. For example the Measurement Method could be "compare the traffic with a fin= gerprint" and the associated Measurement Task "compare the traffic on incom= ing interface #3 with fingerprint #17 starting at UTC 13:01 and 58.6 second= s on 2013-06-15" >=20 > What matter here, it's the overall repartition of the intelligence > between each logical component of the measurement system. Passive > measurement method will need to put more intelligence in the MA. >=20 > 3.1 Other potentially useful terminology >=20 > Measurement Parameter and Environmental Constraint >=20 > Same as before : it's in the measurement method if it's needed. correct >=20 > I think you should create a distinct paragraph for the measurement > method. Not sure what you mean - there's a paragraph where Measurement Method is de= fined >=20 > 4. Commentary and notes >=20 > "By definition a Measurement Peer does not interact with a Controller > or Collector" >=20 > Not sure it's a wise idea : the measurement method will have to ensure > that the peer or landmark is for example not overloaded, or correctly > on time, or just alive. Why not saying that the measurement controller > is also tracking some states of measurement peer or landmark and will > then either postpone some future measurement to this landmark ? > If you choose to not do so, measurement method will need mix their > primary functionality : do measurement and also check that should be > part of the measurement method : can I do the measurement with the peer > or landmark ? The thinking is that, as a "pre" part of the measurement method, the Measur= ement Agent may check with the Measurement Peer (/Landmark) that it can run= the test (it's not overloaded etc). some people call this "admission contr= ol". I think that sometimes "admission control" will be done and sometimes = it won't - depends on the type of test (how much could it load up the Peer)= , whether you have some other way of alleviating potential issues (eg load = balancing at the Peer), whether the Measurement Method itself incorporates = a back-off algorithm, how much risk you're prepared to take (of overloading= the Peer), whether it's easier to detect/delete "dodgy" measurement result= s etc An alternative is for the "admission control" to involve the Measurement Co= ntroller. Personally I don't like this - it means that there has to be comm= unication involving the Controller, Peer and MA before every single Measure= ment Task is involved in this process, and also it won't work if the Peer i= s a non-IPPM/LMAP device.=20 >=20 > Cheers. >=20 > -- > J=E9r=F4me Benoit aka fraggle > La M=E9t=E9o du Net - http://grenouille.com > OpenPGP Key ID : 9FE9161D > Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D From j.schoenwaelder@jacobs-university.de Fri May 3 01:30:18 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F25F21F9457 for ; Fri, 3 May 2013 01:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wHP+I7FBaI6 for ; Fri, 3 May 2013 01:30:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1262321F9488 for ; Fri, 3 May 2013 01:30:13 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BDE320C0E; Fri, 3 May 2013 10:30:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xuyaqq7IP0i0; Fri, 3 May 2013 10:30:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0A5C20C0C; Fri, 3 May 2013 10:30:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6B7A725F27A6; Fri, 3 May 2013 10:30:11 +0200 (CEST) Date: Fri, 3 May 2013 10:30:11 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20130503083011.GB4483@elstar.local> Mail-Followup-To: philip.eardley@bt.com, jerome.benoit@grenouille.com, lmap@ietf.org References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> <20130502170635.714505d5@nemesis.grenouille.com> <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: jerome.benoit@grenouille.com, lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 08:30:18 -0000 On Fri, May 03, 2013 at 09:23:47AM +0100, philip.eardley@bt.com wrote: > > 2. Summary > > > > I dislike the terminology "Measurement Peer", I prefer "Measurement > > Landmarks". The measurement agent with talk to different peer (MC, > > etc.), only one or several of these peer(s) will be used to target the > > measurement task. > > Measurement Peer vs Landmark - I'm easy either way. > I do not follow your argument. We call it a 'Measurement Peer' and obviously this is not a 'Controller' nor a 'Collector'. I fail to see why there can be any confusion because we call it 'Measurement Peer' and not just 'peer'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From acmorton@att.com Fri May 3 05:09:43 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5548721F90B1 for ; Fri, 3 May 2013 05:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.348 X-Spam-Level: X-Spam-Status: No, score=-106.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFHN6m16WuaW for ; Fri, 3 May 2013 05:09:37 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id EAC9121F8FC7 for ; Fri, 3 May 2013 05:09:36 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id DDCB71205C9; Fri, 3 May 2013 08:09:35 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id 0E12DEF69A; Fri, 3 May 2013 08:09:36 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Fri, 3 May 2013 08:09:35 -0400 From: "MORTON JR., ALFRED C (AL)" To: Juergen Schoenwaelder , "philip.eardley@bt.com" Date: Fri, 3 May 2013 08:09:34 -0400 Thread-Topic: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt Thread-Index: Ac5H2HpyrbCDXhZ/SuGKa5Di4SFqFgAHPOiQ Message-ID: References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> <20130502170635.714505d5@nemesis.grenouille.com> <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net> <20130503083011.GB4483@elstar.local> In-Reply-To: <20130503083011.GB4483@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 Cc: "jerome.benoit@grenouille.com" , "lmap@ietf.org" Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 12:09:43 -0000 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: Friday, May 03, 2013 4:30 AM > To: philip.eardley@bt.com > Cc: jerome.benoit@grenouille.com; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap- > terminology-01.txt >=20 > On Fri, May 03, 2013 at 09:23:47AM +0100, philip.eardley@bt.com wrote: > > > 2. Summary > > > > > > I dislike the terminology "Measurement Peer", I prefer "Measurement > > > Landmarks". The measurement agent with talk to different peer (MC, > > > etc.), only one or several of these peer(s) will be used to target th= e > > > measurement task. > > > > Measurement Peer vs Landmark - I'm easy either way. > > >=20 > I do not follow your argument. We call it a 'Measurement Peer' and > obviously this is not a 'Controller' nor a 'Collector'. I fail to see > why there can be any confusion because we call it 'Measurement Peer' > and not just 'peer'. >=20 > /js >=20 To me, a "Landmark" would have a single specific position in the architectu= re, and that meaning overlaps with the "measurement points" specified in the=20 Reference path draft. A measurement peer can be anywhere in the network, which is the sort of generality needed at the control level. Also, the Controller and MA are not peers, certainly not in the way that two MAs can be peers when=20 they coordinate to perform tests. Al From jerome.benoit@grenouille.com Fri May 3 08:50:42 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AAD21F8D94 for ; Fri, 3 May 2013 08:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFU1P7dTjNal for ; Fri, 3 May 2013 08:50:27 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC9121F8E84 for ; Fri, 3 May 2013 08:07:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 08FBE7F6FF; Fri, 3 May 2013 17:07:03 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJSJpjvkMk9A; Fri, 3 May 2013 17:06:50 +0200 (CEST) Date: Fri, 3 May 2013 17:06:49 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: "MORTON JR., ALFRED C (AL)" Message-ID: <20130503170649.3aa14ad2@nemesis.grenouille.com> In-Reply-To: References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> <20130502170635.714505d5@nemesis.grenouille.com> <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net> <20130503083011.GB4483@elstar.local> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/.qPgoy/dB2Paqo1jHN.kItd"; protocol="application/pgp-signature" Cc: "philip.eardley@bt.com" , Juergen Schoenwaelder , "lmap@ietf.org" Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 15:50:43 -0000 --Sig_/.qPgoy/dB2Paqo1jHN.kItd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, 3 May 2013 08:09:34 -0400 in , MORTON JR., ALFRED C (AL) "MORTON JR., ALFRED C (AL)" wrote: >=20 > To me, a "Landmark" would have a single specific position in the architec= ture, > and that meaning overlaps with the "measurement points" specified in the= =20 > Reference path draft. A landmark is a peer on steroid : It can do some treatment on the received packets (whatever layer) : mirroring -layer 3-, simulate layer 7 protocol, etc. It's basically a targeted implementation of a sockets server (using RAW sockets and with pluggable "treatment" on the received packets) =20 The basic network functionalities that all OSes offer (ICMP, TCP, UDP) being network element, endpoint, firewall permit to do some measurement but the most common part of each active measurement is one or s= everal intelligent endpoints. =20 >=20 > A measurement peer can be anywhere in the network, which is the sort > of generality needed at the control level. Also, the Controller and MA > are not peers, certainly not in the way that two MAs can be peers when=20 > they coordinate to perform tests. >=20 Can we call them measurement endpoint (them being intelligent or not) ? --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/.qPgoy/dB2Paqo1jHN.kItd Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGD0okACgkQ+qDLUJ/pFh1S9gCg5WbKv+HIxAWdbjadxwCkOSKQ kFUAnAidWWHCOXGjKkbOYZ0oXGD31Pow =0xt5 -----END PGP SIGNATURE----- --Sig_/.qPgoy/dB2Paqo1jHN.kItd-- From jerome.benoit@grenouille.com Fri May 3 10:22:47 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08B721F84A7 for ; Fri, 3 May 2013 10:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXnflYoij9o6 for ; Fri, 3 May 2013 10:22:24 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id DAAB221F963C for ; Fri, 3 May 2013 09:27:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id E98067F22A; Fri, 3 May 2013 18:27:02 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMU59hTfHBte; Fri, 3 May 2013 18:26:46 +0200 (CEST) Date: Fri, 3 May 2013 18:23:11 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: "Guangqing Deng" Message-ID: <20130503182311.31fe8151@nemesis.grenouille.com> In-Reply-To: <201305030936078772791@cnnic.cn> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130502161407.7e71a328@nemesis.grenouille.com> <201305030936078772791@cnnic.cn> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/jpmI_nES.z0iJnOQ9liPhkS"; protocol="application/pgp-signature" Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:22:48 -0000 --Sig_/jpmI_nES.z0iJnOQ9liPhkS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, 3 May 2013 09:36:08 +0800 in <201305030936078772791@cnnic.cn>,=20 Guangqing Deng "Guangqing Deng" wrote: > IMO, if the work of architecting a 3rd party measurement system is separa= ted into some parts by someone who has expertise on that, it is convenient = for those who have interest on this work to join in this activity, pick a p= iece of work and achieve expected results within a limited period of time. We (grenouille.com) will hopefully have to work on the design and implementation side by side of such a system for three years and make RFCs are part of the work. I said hopefully, because we wait for a response that will fund such a big project. =20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/jpmI_nES.z0iJnOQ9liPhkS Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGD5G8ACgkQ+qDLUJ/pFh0nXQCff5BDVUjt7GYwnQZBq61eUa+v FdcAoJV1E2k1AkkWK33QO5jTyMw1ivgU =IzV4 -----END PGP SIGNATURE----- --Sig_/jpmI_nES.z0iJnOQ9liPhkS-- From jerome.benoit@grenouille.com Fri May 3 10:30:44 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4F721F84D6 for ; Fri, 3 May 2013 10:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBaBoj6hwGmK for ; Fri, 3 May 2013 10:30:39 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 322F321F901B for ; Fri, 3 May 2013 09:16:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 2854B7F0EB; Fri, 3 May 2013 18:16:57 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfev4M6z74Gr; Fri, 3 May 2013 18:16:46 +0200 (CEST) Date: Fri, 3 May 2013 18:16:45 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: Message-ID: <20130503181645.44c92e9d@nemesis.grenouille.com> In-Reply-To: <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net> References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> <20130502170635.714505d5@nemesis.grenouille.com> <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/1Zq1PXU58h0q9LShYwdI6p5"; protocol="application/pgp-signature" Cc: lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:30:44 -0000 --Sig_/1Zq1PXU58h0q9LShYwdI6p5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, 3 May 2013 09:23:47 +0100 in <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.n= et>, philip.eardley@bt.com wrote: > >=20 > > Why do you use "function" everywhere ? It's a functionality. > >=20 >=20 > I don't think there's a clear difference between function and functionali= ty. Functionality roughly seems to mean a set of functions. At least functi= on is less typing! Well ... :) You need a set of functions to implement a measurement task for example.=20 >=20 > > Measurement Method vs. Measurement Task vs. Passive Measurement Method > > > Use case one : I choose to not put the TCP session inter-packets delay > > calculation on the measurement agent, I just extract the timestamp and > > sequence number of each packets in one TCP session and sent them. >=20 > I'd say that the Measurement Method (which is Passive) is to "extract the= timestamp and sequence number of every packet in a TCP session", whilst th= e associated (Passive) Measurement Task would be something like "for the TC= P session from the source 192.0.2.0 destined for 198.51.100.0 and starting = at UTC 13:01 and 58.6 seconds on 2013-06-15, then extract the timestamp and= sequence number of every packet in the TCP session" >=20 > > Use case two : To bootstrap a passive measurement that will detect > > network anomalies, I need to build a "fingerprint" database of network > > behaviours, to do so, I need to send something that will look like a > > netflow data model to build such a fingerprint database. This use case > > is more a bootstrapping measurement method to permit to build a passive > > measurement method. >=20 > For example the Measurement Method could be "compare the traffic with a f= ingerprint" and the associated Measurement Task "compare the traffic on inc= oming interface #3 with fingerprint #17 starting at UTC 13:01 and 58.6 seco= nds on 2013-06-15" OK. fine.=20 > >=20 > > I think you should create a distinct paragraph for the measurement > > method. >=20 > Not sure what you mean - there's a paragraph where Measurement Method is = defined Do not differentiate active and passive measurement method in the terminology. A measurement method can be both, just state the difference in the definition and the derived measurement task will fellow the method (active or passive). =20 >=20 > >=20 > > 4. Commentary and notes > >=20 > > "By definition a Measurement Peer does not interact with a Controller > > or Collector" > >=20 > > Not sure it's a wise idea : the measurement method will have to ensure > > that the peer or landmark is for example not overloaded, or correctly > > on time, or just alive. Why not saying that the measurement controller > > is also tracking some states of measurement peer or landmark and will > > then either postpone some future measurement to this landmark ? > > If you choose to not do so, measurement method will need mix their > > primary functionality : do measurement and also check that should be > > part of the measurement method : can I do the measurement with the peer > > or landmark ? >=20 > The thinking is that, as a "pre" part of the measurement method, the Meas= urement Agent may check with the Measurement Peer (/Landmark) that it can r= un the test (it's not overloaded etc). some people call this "admission con= trol". I think that sometimes "admission control" will be done and sometime= s it won't - depends on the type of test (how much could it load up the Pee= r), whether you have some other way of alleviating potential issues (eg loa= d balancing at the Peer), whether the Measurement Method itself incorporate= s a back-off algorithm, how much risk you're prepared to take (of overloadi= ng the Peer), whether it's easier to detect/delete "dodgy" measurement resu= lts etc I've read the thread on CAC and I responded : It's much more complicated than introducing a simple CAC mechanism on the Measurement Peer/Landmark/Enpoint. The primary use case is :=20 * P2P overlay measurement method;=20 * The derived measurement task;=20 * The metrics of interest collected during the measurement;=20 This measurement method will exhibit the first constraint : the number of active Peer/Endpoint/Landmark that have the capability or functionality to do the measurement task =3D> you need a MA states and capabilities tracker. The second constraint is the network load induced by such a measurement =3D> you need a dependency on a other measurement method and derived task that will be able to evaluate the link capacity between each MA or pull the ISP network elements load to stop the measurement quickly. The third constraint is a that the Peer/Landmark/Endpoint can be reached (most MA are runt behind a CPE, most CPE have a firewall with different security level -traceroute with UDP are not possible with some default security level settings-, most CPE support UPnP, some UPnP implementation in CPE are problematic) So to resume :=20 * CAC between MA and M Peer/Landmark/Endpoint can be enough most of the time * The current design of the LMAP lack of much more thought coherency mechanism between each logical component to permit to run ends to ends measurement (MAs talk to MAs). To solve point two, I propose to introduce a MA state and capabilities=20 tracker, make it optional and non mandatory, postponed to most important detailed architecture work before, no pb but please take it into account : such a tracker is a simple key/value store and nowadays, you can find a bunch of implementation of such a store. The work will be on the protocol to interact with such a tracker.=20 Say MA receive M Task MT(i) that have constraint C1 and C2, The MA ask to http://lmap.tracker.domain.tld/total_number_agent_online ad ask to http://lmap.tracker.domain.tld/total_number_agent_online_with_measurement_i= _capabilities=20 before running the measurement task MT(i) to ensure that it can be done. The checks are part of the MT, the intelligence of the decision is part of the MA and the MA contact the tracker (you can make part of the bootstrapping protocol)=20 I've already explained some time ago that this kind of features should be in the measurement system but nobody listen to me (/me crying) :) > An alternative is for the "admission control" to involve the Measurement = Controller. Personally I don't like this - it means that there has to be co= mmunication involving the Controller, Peer and MA before every single Measu= rement Task is involved in this process, and also it won't work if the Peer= is a non-IPPM/LMAP device.=20 Fine. The rationale for CAC implemented this way sound good but (yes, I always have a but :)) I really prefer to not introduce another bias on the peer/landmark/endpoint via the CAC overhead - the system is already full of bias : cross traffic, OS bias, etc. Plus I do not think CAC between MA and Measurement Peer/Landmark/Endpoint will cover all use case. The point of the tracker is to permit to give to MA information on the measurement system and let the MA decide want to do for a MT.=20 Cheers. =20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/1Zq1PXU58h0q9LShYwdI6p5 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGD4u0ACgkQ+qDLUJ/pFh31VQCcDvDLQ+Q7/lq/E13Ec/BDNQLd CUEAnREAnpIhtNhJXVFCA2JhV1HPdDs0 =/t/N -----END PGP SIGNATURE----- --Sig_/1Zq1PXU58h0q9LShYwdI6p5-- From acmorton@att.com Fri May 3 10:31:59 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F7C21F9766 for ; Fri, 3 May 2013 10:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.7 X-Spam-Level: X-Spam-Status: No, score=-103.7 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx8D7JTdslv1 for ; Fri, 3 May 2013 10:31:53 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0767E21F9988 for ; Fri, 3 May 2013 09:41:27 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 4CE071208CD; Fri, 3 May 2013 12:41:27 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id 75235F00EC; Fri, 3 May 2013 12:41:27 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Fri, 3 May 2013 12:41:27 -0400 From: "MORTON JR., ALFRED C (AL)" To: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= Date: Fri, 3 May 2013 12:41:26 -0400 Thread-Topic: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt Thread-Index: Ac5ID+s/B3i4MROrTXCZ2NJpOVDEAAACoHtA Message-ID: References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> <20130502170635.714505d5@nemesis.grenouille.com> <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net> <20130503083011.GB4483@elstar.local> <20130503170649.3aa14ad2@nemesis.grenouille.com> In-Reply-To: <20130503170649.3aa14ad2@nemesis.grenouille.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philip.eardley@bt.com" , Juergen Schoenwaelder , "lmap@ietf.org" Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:31:59 -0000 J=E9r=F4me, please see brief replies below, > -----Original Message----- > From: J=E9r=F4me Benoit [mailto:jerome.benoit@grenouille.com] > Sent: Friday, May 03, 2013 11:07 AM > To: MORTON JR., ALFRED C (AL) > Cc: Juergen Schoenwaelder; philip.eardley@bt.com; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap- > terminology-01.txt >=20 > On Fri, 3 May 2013 08:09:34 -0400 in > = , > MORTON JR., ALFRED C (AL) "MORTON JR., ALFRED C (AL)" > wrote: >=20 >=20 > > > > To me, a "Landmark" would have a single specific position in the > architecture, > > and that meaning overlaps with the "measurement points" specified in th= e > > Reference path draft. >=20 > A landmark is a peer on steroid : It can do some treatment on the > received packets (whatever layer) : mirroring -layer 3-, simulate > layer 7 protocol, etc. It's basically a targeted implementation of a > sockets server (using RAW sockets and with pluggable "treatment" on > the received packets) [acm] The "steroids" seem to be a description of specific measurement capab= ilities. The names in the terminology draft were intended to have a generic purpose, so devices can eventually include some capabilities and some not,=20 all to be decided when there is an agreed-on characterization plan. >=20 > The basic network functionalities that all OSes offer (ICMP, TCP, UDP) > being network element, endpoint, firewall permit to do some > measurement but the most common part of each active measurement is one or > several > intelligent endpoints. >=20 > > > > A measurement peer can be anywhere in the network, which is the sort > > of generality needed at the control level. Also, the Controller and MA > > are not peers, certainly not in the way that two MAs can be peers when > > they coordinate to perform tests. > > >=20 > Can we call them measurement endpoint (them being intelligent or not) ? [acm] You can, but in some measurement scenarios like single-point passive = measurement (the measurement point is not at the end of anything) it won't be accurate. No ends, no peers, just a Measurement Agent doing its job at a measurement = point. Al >=20 > -- > J=E9r=F4me Benoit aka fraggle > La M=E9t=E9o du Net - http://grenouille.com > OpenPGP Key ID : 9FE9161D > Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D From dengguangqing@cnnic.cn Sat May 4 03:16:14 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070F921F960C for ; Sat, 4 May 2013 03:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.706 X-Spam-Level: X-Spam-Status: No, score=0.706 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRpdgX+7dtVY for ; Sat, 4 May 2013 03:16:10 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 0431121F9617 for ; Sat, 4 May 2013 03:16:08 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO dgq-pc) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 04 May 2013 18:15:57 +0800 Date: Sat, 4 May 2013 18:16:03 +0800 From: "Guangqing Deng" To: "Juergen Schoenwaelder" References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> <20130502170635.714505d5@nemesis.grenouille.com> <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net>, <20130503083011.GB4483@elstar.local> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201305041816029388903@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart456436478688_=----" Cc: "lmap@ietf.org" Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dengguangqing List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 10:16:14 -0000 This is a multi-part message in MIME format. ------=_001_NextPart456436478688_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEp1ZXJnZW4sIG9uY2UgSSBzZWUgdGhlIHRlcm0gIm1lYXN1cmVtZW50IHBlZXIiLCB3aGF0 IGNvbWVzIGludG8gbXkgbWluZCBuZXh0DQppcyB0aGUgdGVybSAibWVhc3VyZW1lbnQgc2VydmVy Ii4gTWF5YmUgdGhhdCBpcyBiZWNhdXNlIG9mIHRoZSBwZWVyLXRvLXBlZXIgbmV0d29yayANCndo ZXJlIHRoZSAicGVlciIgYW5kICJzZXJ2ZXIiIGFyZSB0aGUgdHdvIGJhc2ljIHJvbGVzIG9mIHRo aXMga2luZCBvZiBuZXR3b3JrLiBCdXQgdGhlIA0KdGVybSAibWVhc3VyZW1lbnQgcGVlciIgaXMg T2sgZm9yIG1lIGlmIGEgbW9yZSBzdWl0YWJsZSB0ZXJtIGhhcyBub3QgYmVlbiBmb3VuZC4NCg0K DQoNCg0KR3VhbmdxaW5nIERlbmcNCmNubmljIA0KDQpGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxk ZXINCkRhdGU6IDIwMTMtMDUtMDMgMTY6MzANClRvOiBwaGlsaXAuZWFyZGxleQ0KQ0M6IGplcm9t ZS5iZW5vaXQ7IGxtYXANClN1YmplY3Q6IFJlOiBbbG1hcF0gRlc6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtZWFyZGxleS1sbWFwLXRlcm1pbm9sb2d5LTAxLnR4dA0KT24gRnJp LCBNYXkgMDMsIDIwMTMgYXQgMDk6MjM6NDdBTSArMDEwMCwgcGhpbGlwLmVhcmRsZXlAYnQuY29t IHdyb3RlOg0KPiA+IDIuICBTdW1tYXJ5DQo+ID4gDQo+ID4gSSBkaXNsaWtlIHRoZSB0ZXJtaW5v bG9neSAiTWVhc3VyZW1lbnQgUGVlciIsIEkgcHJlZmVyICJNZWFzdXJlbWVudA0KPiA+IExhbmRt YXJrcyIuIFRoZSBtZWFzdXJlbWVudCBhZ2VudCB3aXRoIHRhbGsgdG8gZGlmZmVyZW50IHBlZXIg KE1DLA0KPiA+IGV0Yy4pLCBvbmx5IG9uZSBvciBzZXZlcmFsIG9mIHRoZXNlIHBlZXIocykgd2ls bCBiZSB1c2VkIHRvIHRhcmdldCB0aGUNCj4gPiBtZWFzdXJlbWVudCB0YXNrLg0KPiANCj4gTWVh c3VyZW1lbnQgUGVlciB2cyBMYW5kbWFyayAtIEknbSBlYXN5IGVpdGhlciB3YXkuDQo+IA0KDQpJ IGRvIG5vdCBmb2xsb3cgeW91ciBhcmd1bWVudC4gV2UgY2FsbCBpdCBhICdNZWFzdXJlbWVudCBQ ZWVyJyBhbmQNCm9idmlvdXNseSB0aGlzIGlzIG5vdCBhICdDb250cm9sbGVyJyBub3IgYSAnQ29s bGVjdG9yJy4gSSBmYWlsIHRvIHNlZQ0Kd2h5IHRoZXJlIGNhbiBiZSBhbnkgY29uZnVzaW9uIGJl Y2F1c2Ugd2UgY2FsbCBpdCAnTWVhc3VyZW1lbnQgUGVlcicNCmFuZCBub3QganVzdCAncGVlcicu DQoNCi9qcw0KDQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVu aXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENh bXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMx MDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbG1hcCBtYWlsaW5nIGxpc3QN CmxtYXBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1h cA== ------=_001_NextPart456436478688_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi, Juergen,=20 once I see the term "measurement peer", = ;what comes into my mind next
is the term "measurement server". Maybe = ;that is because of=20 the peer-to-peer network 
where the "peer" and "server" are the&n= bsp;two basic roles=20 of this kind of network. But the 
term "measurement peer" is Ok for me&nb= sp;if a more suitable term has not been=  found.
 
Gua= ngqing=20 Deng
cnnic 
 
From: Juergen=20 Schoenwaelder
Date: 2013-05-03 16:30
To: philip.eardley
CC: jerome.benoit; lmap
Subject: Re: [lmap] FW: New Version Notification for=20 draft-eardley-lmap-terminology-01.txt
On Fri, May 03, 2013 at 09:23:47AM = ;+0100, philip.eardley@bt.com wrote:
> > 2.  Summary
> > 
> > I dislike the terminology "Me= asurement Peer", I prefer "Measurement
> > Landmarks". The measurement agent&= nbsp;with talk to different peer (MC,
> > etc.), only one or several&nb= sp;of these peer(s) will be used to tar= get the
> > measurement task.
> 
> Measurement Peer vs Landmark - I'm=  easy either way.
> 
 
I do not follow your argument. We = call it a 'Measurement Peer' and
obviously this is not a 'Controller' no= r a 'Collector'. I fail to see
why there can be any confusion because&= nbsp;we call it 'Measurement Peer'
and not just 'peer'.
 
/js
 
-- 
Juergen Schoenwaelder       &= nbsp;   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587    &n= bsp;    Campus Ring 1, 28759 Breme= n, Germany
Fax:   +49 421 200 3103  &nbs= p;      <http://www.jacobs-university.de/= >
_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap
------=_001_NextPart456436478688_=------ From j.schoenwaelder@jacobs-university.de Sat May 4 03:29:11 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA6521F9616 for ; Sat, 4 May 2013 03:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6dgn5lVpyQ9 for ; Sat, 4 May 2013 03:29:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 024EC21F960C for ; Sat, 4 May 2013 03:29:06 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BBF120C10; Sat, 4 May 2013 12:29:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oZYf5BuU9anQ; Sat, 4 May 2013 12:29:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9D1320C0B; Sat, 4 May 2013 12:29:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 85E66260324B; Sat, 4 May 2013 12:29:02 +0200 (CEST) Date: Sat, 4 May 2013 12:29:02 +0200 From: Juergen Schoenwaelder To: Guangqing Deng Message-ID: <20130504102902.GA45114@elstar.local> Mail-Followup-To: Guangqing Deng , "lmap@ietf.org" References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> <20130502170635.714505d5@nemesis.grenouille.com> <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net> <20130503083011.GB4483@elstar.local> <201305041816029388903@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201305041816029388903@cnnic.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "lmap@ietf.org" Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 10:29:11 -0000 On Sat, May 04, 2013 at 06:16:03PM +0800, Guangqing Deng wrote: > Hi, Juergen, once I see the term "measurement peer", what comes into my mind next > is the term "measurement server". Maybe that is because of the peer-to-peer network > where the "peer" and "server" are the two basic roles of this kind of network. But the > term "measurement peer" is Ok for me if a more suitable term has not been found. > Measurement server was an early term but then people argued that this thing may not necessary act as a server for the measurement to be performed and hence we now have measurement peer since it is more neutral. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Sun May 5 08:46:54 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405D221F9322 for ; Sun, 5 May 2013 08:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yftptdAavCao for ; Sun, 5 May 2013 08:46:50 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BC15321F92F7 for ; Sun, 5 May 2013 08:46:49 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r45FkdGX017020; Sun, 5 May 2013 17:46:39 +0200 (CEST) Received: from [10.61.213.251] ([10.61.213.251]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r45FjFTa008433; Sun, 5 May 2013 17:45:25 +0200 (CEST) Message-ID: <51867E8B.5060502@cisco.com> Date: Sun, 05 May 2013 16:45:15 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: philip.eardley@bt.com References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lmap@ietf.org, trevor.burbridge@bt.com, j.schoenwaelder@jacobs-university.de, Michael.K.Bugenhagen@centurylink.com, jason.weil@twcable.com, shane@castlepoint.net, bs7652@att.com Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 15:46:54 -0000 Philip, > Since Benoit probably won't read all 44 emails in this thread, I tried to draft an answer to his original question. I read them all, but with a little bit of delay, as you can see. Your summary is very much appreciated See in line. > Is it a fair summary of the consensus? > >> Question 1. Use cases >> Do we agree that we want to focus on the Internet Service Provider and >> the End User Network Diagnostics use cases for now? As a phase 2, we >> could focus on the 3rd party use case: multi-provider, regulator, over >> the top >> Question: in the End User Network Diagnostics use case, I'm unclear if >> the user initiated measurement is included? > Here's a proposed answer:- > > In order to simplify the security and policy considerations, we propose that LMAP phase 1 should make the assumption that the measurement system is under the control of a single organisation. 'Measurement system' refers to the Measurement Agent, Controller and Collector. There is likely to be interest in LMAP phase 2 in scenarios where the measurement system is not under the control of a single organisation. > > Note that the Measurement Peer may be under another organisation's control (for example, the Measurement Peer might be in example.com, with the Measurement Task to download example.com's homepage or to send a request to its DNS server). However, this doesn't affect LMAP's 'single organisation' assumption since the job of defining Measurement Tasks is left to IPPM. > > > So in terms of Benoit's questions: > - The Internet Service Provider use case is in scope, assuming that the ISP controls the functions for the Measurement Agent, Controller and Collector > - The regulator use case is in scope, assuming that the regulator controls the functions for the Measurement Agent, Controller and Collector I'm wondering whether the previous two points are not incompatible? Most ISPs have, or will have, a type of LMAP architecture anyway. When I call my provider (home network), they can already do the type of LMAP tests on my router. So what use case is left of the regulator (knowing the assumption that a MA is under the administration of a single entity)? Regards, Benoit > - The End User Network Diagnostics use case is not directly in scope. However, the end user can get its MA to run Measurement Tasks if it wants and report results to whoever it wants; LMAP doesn't try to stop this happening. > > > > On separate topics (but should be mentioned somewhere in reply to Benoit) > > Discussion has revealed one new capability that may be required. Before a Measurement Task actually runs, the Measurement Agent may need to check that the Peer can carry out the Task. If one considers this as an initial stage of the Task, then it would be something for IPPM to define. > > We have also discussed about the bootstrapping of a Measurement Agent (for example, about what Controller to contact). Here the consensus is to define the process but not a protocol. Because bootstrapping could be done in different ways, depending on the device and the measurement system, for instance: loaded at manufacture, updated locally via USB port, or orchestrated via a protocol. > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > From bclaise@cisco.com Mon May 6 08:17:57 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF1921F8C10 for ; Mon, 6 May 2013 08:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI+IU7Mi4zYg for ; Mon, 6 May 2013 08:17:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D5F0921F8D27 for ; Mon, 6 May 2013 08:17:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r46FHjo2005939 for ; Mon, 6 May 2013 17:17:45 +0200 (CEST) Received: from [10.61.214.134] ([10.61.214.134]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r46FHGvM014190 for ; Mon, 6 May 2013 17:17:26 +0200 (CEST) Message-ID: <5187C97C.7080409@cisco.com> Date: Mon, 06 May 2013 16:17:16 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "lmap@ietf.org" Content-Type: multipart/alternative; boundary="------------080106020805040404060605" Subject: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 15:17:57 -0000 This is a multi-part message in MIME format. --------------080106020805040404060605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I'm not sure I've seen (much) discussion on this topic *Question 4: Measurement Agent device type* A branch office router, a home router, a dual home router, a laptop, a tablet, a mobile device, ...? The discussion started on the list with an email sent on March 7th, with the "[lmap] Which devices does LMAP target?" subject. This needs more discussion. The requirements will be different based on the device type (ex: router versus tablet versus mobile). On my mobile, for which I pay per transmitted bytes, I don't want to pay for those measurements. This comes back to the question of voluntary based measurements or not? I'm concerned that the scope might be too big if we take all these device types into account. People spoke on the list about "service parameters". I agree that these are important to combine with the measurement reports. On a PC, table, or even a mobile device using wireless, how would I know the service parameters? How would I make the link with my router service status? Multi-provider home is not a uncommon case these days... Mobiles have multiple connections these days: IPv4/IPv6, 3G, and change constantly based on the best QoE. We would have to deal with a discovery protocol, or a traceroute-based type of measurements. Regards, Benoit --------------080106020805040404060605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I'm not sure I've seen (much) discussion on this topic
Question 4: Measurement Agent device type
A branch office router, a home router, a dual home router, a laptop, a tablet, a mobile device, ...?
The discussion started on the list with an email sent on March 7th, with the "[lmap] Which devices does LMAP target?" subject. This needs more discussion.
The requirements will be different based on the device type (ex: router versus tablet versus mobile). 
On my mobile, for which I pay per transmitted bytes, I don't want to pay for those measurements. This comes back to the question of voluntary based measurements or not?
I'm concerned that the scope might be too big if we take all these device types into account.
People spoke on the list about "service parameters". I agree that these are important to combine with the measurement reports.
On a PC, table, or even a mobile device using wireless, how would I know the service parameters? How would I make the link with my router service status? Multi-provider home is not a uncommon case these days...
Mobiles have multiple connections these days: IPv4/IPv6, 3G, and change constantly based on the best QoE.
We would have to deal with a discovery protocol, or a traceroute-based type of measurements.

Regards, Benoit
--------------080106020805040404060605-- From j.schoenwaelder@jacobs-university.de Mon May 6 08:34:38 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7032221F8D79 for ; Mon, 6 May 2013 08:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlpMAuiIBORN for ; Mon, 6 May 2013 08:34:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 257BC21F9057 for ; Mon, 6 May 2013 08:34:26 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A422820BDC; Mon, 6 May 2013 17:34:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JA0lLf61-Fsp; Mon, 6 May 2013 17:34:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DCEE20AFE; Mon, 6 May 2013 17:34:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8393B2607E81; Mon, 6 May 2013 17:34:23 +0200 (CEST) Date: Mon, 6 May 2013 17:34:23 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20130506153423.GC54841@elstar.local> Mail-Followup-To: Benoit Claise , "lmap@ietf.org" References: <5187C97C.7080409@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5187C97C.7080409@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 15:34:38 -0000 On Mon, May 06, 2013 at 04:17:16PM +0100, Benoit Claise wrote: > Dear all, > > I'm not sure I've seen (much) discussion on this topic > > *Question 4: Measurement Agent device type* > A branch office router, a home router, a dual home router, a laptop, > a tablet, a mobile device, ...? > The discussion started on the list with an email sent on March 7th, > with the "[lmap] Which devices does LMAP target?" subject. This > needs more discussion. > The requirements will be different based on the device type (ex: > router versus tablet versus mobile). > On my mobile, for which I pay per transmitted bytes, I don't want to > pay for those measurements. This comes back to the question of > voluntary based measurements or not? > > I'm concerned that the scope might be too big if we take all these > device types into account. > People spoke on the list about "service parameters". I agree that > these are important to combine with the measurement reports. > On a PC, table, or even a mobile device using wireless, how would I > know the service parameters? How would I make the link with my > router service status? Multi-provider home is not a uncommon case > these days... > Mobiles have multiple connections these days: IPv4/IPv6, 3G, and > change constantly based on the best QoE. > We would have to deal with a discovery protocol, or a > traceroute-based type of measurements. I hear you talking about network access options that MAs have and not really device types. But even then, it is unclear what your question really is. - For certain MAs, the measurement traffic volume may be an issue. Yes. So we may need to be able to announce the estimated network bandwidth consumed so that people can take an informed decisions whether the allow/disallow certain tests to be performed by MAs. For other deployments, e.g. the operator use case, one would hope that measurements that benefit the operator would not be counted towards the traffic volume of the subscriber (but that would be a contractual / policy issue beyond the IETF's scope). - For certain MAs, it will be difficult to obtain the service line parameters. Yes. There is was a debate whether MAs should be involved in the communication of line parameters. Perhaps MAs be able to provide sufficient information about the test results such that the network access used can be determined if necessary. This might be all line parameters if that information is accessible to the MA or at least information sufficient to determine the beginning of the network path used. I do no think that ruling out device types helps us much. I see it more of a need to determine requirements about how much contextual information is desirable and at the same time to discuss the privacy issues involved with that. In other words, I do not see this as a charter scoping issue (in case that is driving your question). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Mon May 6 15:06:38 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AEA21F8F25 for ; Mon, 6 May 2013 15:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgiWRVNhyCOi for ; Mon, 6 May 2013 15:06:34 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9F121F8EE8 for ; Mon, 6 May 2013 15:06:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r46M6X51011707 for ; Tue, 7 May 2013 00:06:33 +0200 (CEST) Received: from [10.61.197.24] ([10.61.197.24]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r46M62dG011181 for ; Tue, 7 May 2013 00:06:13 +0200 (CEST) Message-ID: <5188294A.9050409@cisco.com> Date: Mon, 06 May 2013 23:06:02 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "lmap@ietf.org" References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> In-Reply-To: <20130506153423.GC54841@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 22:06:38 -0000 On 6/05/2013 16:34, Juergen Schoenwaelder wrote: > On Mon, May 06, 2013 at 04:17:16PM +0100, Benoit Claise wrote: >> Dear all, >> >> I'm not sure I've seen (much) discussion on this topic >> >> *Question 4: Measurement Agent device type* >> A branch office router, a home router, a dual home router, a laptop, >> a tablet, a mobile device, ...? >> The discussion started on the list with an email sent on March 7th, >> with the "[lmap] Which devices does LMAP target?" subject. This >> needs more discussion. >> The requirements will be different based on the device type (ex: >> router versus tablet versus mobile). >> On my mobile, for which I pay per transmitted bytes, I don't want to >> pay for those measurements. This comes back to the question of >> voluntary based measurements or not? >> >> I'm concerned that the scope might be too big if we take all these >> device types into account. >> People spoke on the list about "service parameters". I agree that >> these are important to combine with the measurement reports. >> On a PC, table, or even a mobile device using wireless, how would I >> know the service parameters? How would I make the link with my >> router service status? Multi-provider home is not a uncommon case >> these days... >> Mobiles have multiple connections these days: IPv4/IPv6, 3G, and >> change constantly based on the best QoE. >> We would have to deal with a discovery protocol, or a >> traceroute-based type of measurements. > I hear you talking about network access options that MAs have and not > really device types. But even then, it is unclear what your question > really is. Let me explain differently, by asking question. How many MAs do you expect in a branch office? One on the router? How many MAs do you expect to have in a home? One per exit router? One on my IPAD? One on my PC? One on my phone? Those MAs are somehow coordinated? If yes, how? If not, we have 4 times the measurements. The access options are also important One my phone/IPAD connected via wireless, that could be OK One my phone/IPAD connected via 3G, that's not OK with me Focusing the MA on the router (even if there could be multiple access types) reduce the problem space, and this is something that the ISPs do already, except they have proprietary solutions > > - For certain MAs, the measurement traffic volume may be an issue. > > Yes. So we may need to be able to announce the estimated network > bandwidth consumed so that people can take an informed decisions > whether the allow/disallow certain tests to be performed by MAs. > > For other deployments, e.g. the operator use case, one would hope > that measurements that benefit the operator would not be counted > towards the traffic volume of the subscriber (but that would be a > contractual / policy issue beyond the IETF's scope). > > - For certain MAs, it will be difficult to obtain the service line > parameters. > > Yes. There is was a debate whether MAs should be involved in the > communication of line parameters. Perhaps MAs be able to provide > sufficient information about the test results such that the network > access used can be determined if necessary. This might be all line > parameters if that information is accessible to the MA or at least > information sufficient to determine the beginning of the network > path used. > > I do no think that ruling out device types helps us much. I see it > more of a need to determine requirements about how much contextual > information is desirable and at the same time to discuss the privacy > issues involved with that. In other words, I do not see this as a > charter scoping issue (in case that is driving your question). It is! Hence my clarifying questions in http://www.ietf.org/mail-archive/web/lmap/current/msg00368.html Regards, Benoit > > /js > From j.schoenwaelder@jacobs-university.de Mon May 6 22:04:01 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E1C21F9080 for ; Mon, 6 May 2013 22:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IxHl9Cq7Eqk for ; Mon, 6 May 2013 22:03:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C327621F8A7B for ; Mon, 6 May 2013 22:03:52 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C1D020BE0; Tue, 7 May 2013 07:03:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pl8VORk0MsRX; Tue, 7 May 2013 07:03:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1227420BDE; Tue, 7 May 2013 07:03:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7B9292608FCF; Tue, 7 May 2013 07:03:48 +0200 (CEST) Date: Tue, 7 May 2013 07:03:48 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20130507050348.GA56873@elstar.local> Mail-Followup-To: Benoit Claise , "lmap@ietf.org" References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5188294A.9050409@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 05:04:01 -0000 On Mon, May 06, 2013 at 11:06:02PM +0100, Benoit Claise wrote: > Let me explain differently, by asking question. > How many MAs do you expect in a branch office? > One on the router? > How many MAs do you expect to have in a home? > One per exit router? > One on my IPAD? > One on my PC? > One on my phone? > Those MAs are somehow coordinated? > If yes, how? > If not, we have 4 times the measurements. I think the answer will depend on who deploys MAs. For the ISP use case, an MA in the access router (exit router or whatever you call that box) is likely what the ISP needs. If we talk about say TV over IP services, I could see that someone might embed an MA in a TV set (which might do only passive measurements to report characteristics of multi-media streams). If we allow regular users to deploy MAs in order to make independent measurements, I would not be surprised is someone builds an 'app' for popular devices that essentially includes a MA. But then it is a human user who deploys this 'app', likely he/she knows the consequences what what he/she is doing. > The access options are also important > One my phone/IPAD connected via wireless, that could be OK > One my phone/IPAD connected via 3G, that's not OK with me Although an MA doing passive measurements might still be OK on your 3G link from a bandwidth point of view. > Focusing the MA on the router (even if there could be multiple > access types) reduce the problem space, and this is something that > the ISPs do already, except they have proprietary solutions Well, yes, such a restriction might allows the WG to sidestep some discussions. However, from an architectural point of view, I would hope that the resulting technology is at the end general enough to be applied to other use cases and deployments as well. /js PS: And to cover some of today's hardware probe based systems, you would have to replace 'on the router' with 'on or close to the router'. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue May 7 06:07:30 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7D721F86D6 for ; Tue, 7 May 2013 06:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1vEoDcEWYhU for ; Tue, 7 May 2013 06:07:24 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D32D021F8A48 for ; Tue, 7 May 2013 06:07:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsGAI/7iFGHCzI1/2dsb2JhbABQgmYhv0CBBxZtB4IhAQEDEihRARUVFEImAQQbGodqAaEvhDGMdI5VjwCDKmEDk1+KCYp6gw2CJw X-IronPort-AV: E=Sophos;i="4.87,628,1363147200"; d="scan'208";a="8277449" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 May 2013 09:07:08 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 May 2013 09:03:33 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Tue, 7 May 2013 09:07:06 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: LMAP Meeting in Berlin Thread-Index: Ac5LI8YwWOEBZnXyRYe+eOHvbu9ERA== Date: Tue, 7 May 2013 13:07:06 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1662DA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] LMAP Meeting in Berlin X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 13:07:30 -0000 Hi, We discussed with our AD Benoit the status of the formation of the WG and o= ur shared assessment is that although we have made good progress with focus= ing the scope and drafting the charter it is not certain that a WG will be = chartered before IETF-87. In order to make sure that LMAP will have a meeti= ng in Berlin we suggested and Benoit agreed to request a second LMAP BOF. I= f the WG is formed until Berlin this slot will be used for a WG meeting and= the agenda will include the chartered items. If we are not chartered as a = WG by then we shall focus on requirements, use cases, and discussions conce= rning the finalization of the charter.=20 Proposed Duration: 1.5 hours Conflicts List: ippm, bmwg, xrblock, sacm, opsarea, opsawg, eman, netconf, = netmod, dime, radext We included on the conflicts list the meetings of the WGs that we are chair= ing, and the ones that must be attended by Benoit. If there are any other s= trong conflicts to avoid for any of the principal contributors please let u= s know.=20 Any other questions and comments are welcome.=20 Regards, Dan From philip.eardley@bt.com Tue May 7 07:13:20 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D9E21F8F0C for ; Tue, 7 May 2013 07:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu4nr65aVYny for ; Tue, 7 May 2013 07:13:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id C724821F8E79 for ; Tue, 7 May 2013 07:13:15 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 7 May 2013 15:13:14 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.228]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 7 May 2013 15:13:13 +0100 From: To: , Date: Tue, 7 May 2013 15:13:12 +0100 Thread-Topic: [lmap] LMAP: situation: Question 4: Measurement Agent device type Thread-Index: Ac5K4ExNzcQWZjDnTOGVzDserHX8eAASykIA Message-ID: <9510D26531EF184D9017DF24659BB87F346DC9A6E5@EMV65-UKRD.domain1.systemhost.net> References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> <20130507050348.GA56873@elstar.local> In-Reply-To: <20130507050348.GA56873@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 14:13:20 -0000 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: 07 May 2013 06:04 > To: Benoit Claise > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent > device type >=20 > On Mon, May 06, 2013 at 11:06:02PM +0100, Benoit Claise wrote: >=20 > > Let me explain differently, by asking question. > > How many MAs do you expect in a branch office? > > One on the router? > > How many MAs do you expect to have in a home? > > One per exit router? > > One on my IPAD? > > One on my PC? > > One on my phone? > > Those MAs are somehow coordinated? > > If yes, how? > > If not, we have 4 times the measurements. Interesting point. If all the MAs are under the control of the same measurement system, then t= here is some hope that they can be coordinated. In terms of Active Measurem= ent Tasks, the Controller needs to understand that they all use the same ac= cess connection. I guess this should be possible as part of the process whe= n the measurement system deploys the MA function onto the device. However, it's possible that the MAs aren't all under the control of the sam= e measurement system. Perhaps the ISP has deployed the MA on the exit route= r, the regulator the MA on the STB, the user the MA on the tablet etc.=20 I don't think I'd try and coordinate all these MAs. this sounds hard (and i= f the home is connected to 2 access networks, it might be impossible to kno= w which network an MA would use). Perhaps we simply say it's good practice for the measurement tasks to 'list= en before talk' (and perhaps have a back-off algorithm, especially if the t= ask is long-running or heavy-loading) >=20 > I think the answer will depend on who deploys MAs. For the ISP use > case, an MA in the access router (exit router or whatever you call that > box) is likely what the ISP needs. If we talk about say TV over IP > services, I could see that someone might embed an MA in a TV set (which > might do only passive measurements to report characteristics of multi- > media streams). If we allow regular users to deploy MAs in order to > make independent measurements, I would not be surprised is someone > builds an 'app' for popular devices that essentially includes a MA. > But then it is a human user who deploys this 'app', likely he/she knows > the consequences what what he/she is doing. >=20 > > The access options are also important > > One my phone/IPAD connected via wireless, that could be OK > > One my phone/IPAD connected via 3G, that's not OK with me >=20 > Although an MA doing passive measurements might still be OK on your 3G > link from a bandwidth point of view. >=20 > > Focusing the MA on the router (even if there could be multiple access > > types) reduce the problem space, and this is something that the ISPs > > do already, except they have proprietary solutions >=20 > Well, yes, such a restriction might allows the WG to sidestep some > discussions. However, from an architectural point of view, I would hope > that the resulting technology is at the end general enough to be > applied to other use cases and deployments as well. >=20 Agree with Juergen - don't mind this restriction if it helps the chartering= process, but hope the standards would have wider applicability phil >=20 > /js >=20 > PS: And to cover some of today's hardware probe based systems, you > would have to replace 'on the router' with 'on or close to the > router'. >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Tue May 7 07:41:10 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A0121F8630 for ; Tue, 7 May 2013 07:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG7wYgZrp9yr for ; Tue, 7 May 2013 07:41:05 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id B159221F8EF7 for ; Tue, 7 May 2013 07:41:03 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 7 May 2013 15:41:02 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.228]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Tue, 7 May 2013 15:41:01 +0100 From: To: Date: Tue, 7 May 2013 15:41:00 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac5Jp75r9T5jUjWlT7OLjfZsTz1PAQBh/M3w Message-ID: <9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net> References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> <51867E8B.5060502@cisco.com> In-Reply-To: <51867E8B.5060502@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org, trevor.burbridge@bt.com, j.schoenwaelder@jacobs-university.de, Michael.K.Bugenhagen@centurylink.com, jason.weil@twcable.com, shane@castlepoint.net, bs7652@att.com Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 14:41:10 -0000 > > So in terms of Benoit's questions: > > - The Internet Service Provider use case is in scope, assuming that > > the ISP controls the functions for the Measurement Agent, Controller > > and Collector > > - The regulator use case is in scope, assuming that the regulator > > controls the functions for the Measurement Agent, Controller and > > Collector > I'm wondering whether the previous two points are not incompatible? > Most ISPs have, or will have, a type of LMAP architecture anyway. When > I call my provider (home network), they can already do the type of LMAP > tests on my router. So what use case is left of the regulator (knowing > the assumption that a MA is under the administration of a single > entity)? >=20 Not sure I get your point - anyway, I don't think they're incompatible. The MAs, controller and collector(s) are all under common control (single m= easurement system).=20 >From a commercial point of view this looks the same as existing systems - e= ither samknows style measurement systems operated on behalf of a regulator = - or (as you say) where an ISP has measurement functions in a router.=20 Lmap would enable this sort of system to scale better, allow multi-vendor o= peration, etc Thanks phil From philip.eardley@bt.com Tue May 7 07:56:57 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5148821F8E79 for ; Tue, 7 May 2013 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvGib5q8sZWB for ; Tue, 7 May 2013 07:56:52 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD9521F8E96 for ; Tue, 7 May 2013 07:56:52 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 7 May 2013 15:56:51 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.228]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Tue, 7 May 2013 15:56:51 +0100 From: To: Date: Tue, 7 May 2013 15:56:50 +0100 Thread-Topic: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt Thread-Index: Ac5IGaOgntol2DulQPulGbWqiGxTFwDGTPHQ Message-ID: <9510D26531EF184D9017DF24659BB87F346DC9A772@EMV65-UKRD.domain1.systemhost.net> References: <20130502084007.20398.69780.idtracker@ietfa.amsl.com> <9510D26531EF184D9017DF24659BB87F345B116163@EMV65-UKRD.domain1.systemhost.net> <20130502170635.714505d5@nemesis.grenouille.com> <9510D26531EF184D9017DF24659BB87F34684B4CEA@EMV65-UKRD.domain1.systemhost.net> <20130503181645.44c92e9d@nemesis.grenouille.com> In-Reply-To: <20130503181645.44c92e9d@nemesis.grenouille.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 14:56:57 -0000 > So to resume : > * CAC between MA and M Peer/Landmark/Endpoint can be enough most of the > time > * The current design of the LMAP lack of much more thought coherency > mechanism between each logical component to permit to run ends to > ends measurement (MAs talk to MAs). >=20 > To solve point two, I propose to introduce a MA state and capabilities > tracker, make it optional and non mandatory, postponed to most > important detailed architecture work before, no pb but please take it > into account : such a tracker is a simple key/value store and nowadays, > you can find a bunch of implementation of such a store. The work will > be on the protocol to interact with such a tracker. >=20 Ok, I think we agree that the initial charter should concentrate on the "mo= st of the time" scenarios, and leave the optional stuff for later. Thanks phil > Say MA receive M Task MT(i) that have constraint C1 and C2, The MA ask > to http://lmap.tracker.domain.tld/total_number_agent_online > ad ask to > http://lmap.tracker.domain.tld/total_number_agent_online_with_measureme > nt_i_capabilities > before running the measurement task MT(i) to ensure that it can be > done. The checks are part of the MT, the intelligence of the decision > is part of the MA and the MA contact the tracker (you can make part of > the bootstrapping protocol) >=20 > I've already explained some time ago that this kind of features should > be in the measurement system but nobody listen to me (/me crying) :) >=20 > > An alternative is for the "admission control" to involve the > Measurement Controller. Personally I don't like this - it means that > there has to be communication involving the Controller, Peer and MA > before every single Measurement Task is involved in this process, and > also it won't work if the Peer is a non-IPPM/LMAP device. >=20 > Fine. The rationale for CAC implemented this way sound good but (yes, I > always have a but :)) I really prefer to not introduce another bias on > the peer/landmark/endpoint via the CAC overhead - the system is already > full of bias : cross traffic, OS bias, etc. Plus I do not think CAC > between MA and Measurement Peer/Landmark/Endpoint will cover all use > case. The point of the tracker is to permit to give to MA information > on the measurement system and let the MA decide want to do for a MT. >=20 > Cheers. >=20 > -- > J=E9r=F4me Benoit aka fraggle > La M=E9t=E9o du Net - http://grenouille.com > OpenPGP Key ID : 9FE9161D > Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D From acmorton@att.com Tue May 7 10:08:36 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B7121F938E for ; Tue, 7 May 2013 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhX6o0uoK9Mn for ; Tue, 7 May 2013 10:08:29 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id C59C921F881C for ; Tue, 7 May 2013 10:08:27 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id C4E82121CF9; Tue, 7 May 2013 13:08:26 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id EFB37E1EDA; Tue, 7 May 2013 13:08:18 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Tue, 7 May 2013 13:08:26 -0400 From: "MORTON JR., ALFRED C (AL)" To: "philip.eardley@bt.com" , "bclaise@cisco.com" Date: Tue, 7 May 2013 13:08:26 -0400 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac5Jp75r9T5jUjWlT7OLjfZsTz1PAQBh/M3wAAU8cRA= Message-ID: References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> <51867E8B.5060502@cisco.com> <9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" , "trevor.burbridge@bt.com" , "j.schoenwaelder@jacobs-university.de" , "Michael.K.Bugenhagen@centurylink.com" , "jason.weil@twcable.com" , "shane@castlepoint.net" , "STARK, BARBARA H" Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:08:36 -0000 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: Tuesday, May 07, 2013 10:41 AM > To: bclaise@cisco.com > Cc: lmap@ietf.org; trevor.burbridge@bt.com; j.schoenwaelder@jacobs- > university.de; Michael.K.Bugenhagen@centurylink.com; > jason.weil@twcable.com; shane@castlepoint.net; STARK, BARBARA H > Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >=20 > > > So in terms of Benoit's questions: > > > - The Internet Service Provider use case is in scope, assuming that > > > the ISP controls the functions for the Measurement Agent, Controller > > > and Collector > > > - The regulator use case is in scope, assuming that the regulator > > > controls the functions for the Measurement Agent, Controller and > > > Collector > > I'm wondering whether the previous two points are not incompatible? > > Most ISPs have, or will have, a type of LMAP architecture anyway. When > > I call my provider (home network), they can already do the type of LMAP > > tests on my router. So what use case is left of the regulator (knowing > > the assumption that a MA is under the administration of a single > > entity)? > > >=20 > Not sure I get your point - anyway, I don't think they're incompatible. >=20 > The MAs, controller and collector(s) are all under common control (single > measurement system). > From a commercial point of view this looks the same as existing systems - > either samknows style measurement systems operated on behalf of a > regulator - or (as you say) where an ISP has measurement functions in a > router. > Lmap would enable this sort of system to scale better, allow multi-vendor > operation, etc >=20 > Thanks > phil I think, when an ISP has a measurement system, and can provide the required standardized measurements in the regulator's desired format, then the regul= ator's need to deploy their own system would be obviated. If this is what Juergen= =20 meant by incompatible, I get it. Mutually exclusive might be a way express = it. (but see the next message) Al From acmorton@att.com Tue May 7 10:20:23 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7688E21F93EB for ; Tue, 7 May 2013 10:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYqtHEaoJOWt for ; Tue, 7 May 2013 10:20:07 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 54DCC21F93B1 for ; Tue, 7 May 2013 10:20:07 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 7B6C41218BB; Tue, 7 May 2013 13:20:06 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id 06001F015C; Tue, 7 May 2013 13:20:07 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Tue, 7 May 2013 13:20:06 -0400 From: "MORTON JR., ALFRED C (AL)" To: "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" , "bclaise@cisco.com" Date: Tue, 7 May 2013 13:20:05 -0400 Thread-Topic: [lmap] LMAP: situation: Question 4: Measurement Agent device type Thread-Index: Ac5K4ExNzcQWZjDnTOGVzDserHX8eAASykIAAAaCwUA= Message-ID: References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> <20130507050348.GA56873@elstar.local> <9510D26531EF184D9017DF24659BB87F346DC9A6E5@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F346DC9A6E5@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:20:23 -0000 I think overlapping measurement systems may be unavoidable. There's lots of testing to web-based measurement sites today. When users run tests on-demand, they have some purpose in mind and agree to the traffic implications, and to the ISP it's=20 just user traffic (as in no-gaming). But the simplest coordination between systems is that they=20 avoid cross-traffic - and that may mean that user host MAs will not be able to detect when the router MA is trying to=20 a test, for example, and the router test would back-off (seeing user traffic). So here I agree with Phil, listening before (possible during) tests is preferred. Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: Tuesday, May 07, 2013 10:13 AM > To: j.schoenwaelder@jacobs-university.de; bclaise@cisco.com > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device > type >=20 >=20 >=20 > > -----Original Message----- > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > > Juergen Schoenwaelder > > Sent: 07 May 2013 06:04 > > To: Benoit Claise > > Cc: lmap@ietf.org > > Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent > > device type > > > > On Mon, May 06, 2013 at 11:06:02PM +0100, Benoit Claise wrote: > > > > > Let me explain differently, by asking question. > > > How many MAs do you expect in a branch office? > > > One on the router? > > > How many MAs do you expect to have in a home? > > > One per exit router? > > > One on my IPAD? > > > One on my PC? > > > One on my phone? > > > Those MAs are somehow coordinated? > > > If yes, how? > > > If not, we have 4 times the measurements. >=20 > Interesting point. >=20 > If all the MAs are under the control of the same measurement system, then > there is some hope that they can be coordinated. In terms of Active > Measurement Tasks, the Controller needs to understand that they all use > the same access connection. I guess this should be possible as part of th= e > process when the measurement system deploys the MA function onto the > device. >=20 > However, it's possible that the MAs aren't all under the control of the > same measurement system. Perhaps the ISP has deployed the MA on the exit > router, the regulator the MA on the STB, the user the MA on the tablet > etc. > I don't think I'd try and coordinate all these MAs. this sounds hard (and > if the home is connected to 2 access networks, it might be impossible to > know which network an MA would use). > Perhaps we simply say it's good practice for the measurement tasks to > 'listen before talk' (and perhaps have a back-off algorithm, especially i= f > the task is long-running or heavy-loading) >=20 > > > > I think the answer will depend on who deploys MAs. For the ISP use > > case, an MA in the access router (exit router or whatever you call that > > box) is likely what the ISP needs. If we talk about say TV over IP > > services, I could see that someone might embed an MA in a TV set (which > > might do only passive measurements to report characteristics of multi- > > media streams). If we allow regular users to deploy MAs in order to > > make independent measurements, I would not be surprised is someone > > builds an 'app' for popular devices that essentially includes a MA. > > But then it is a human user who deploys this 'app', likely he/she knows > > the consequences what what he/she is doing. > > > > > The access options are also important > > > One my phone/IPAD connected via wireless, that could be OK > > > One my phone/IPAD connected via 3G, that's not OK with me > > > > Although an MA doing passive measurements might still be OK on your 3G > > link from a bandwidth point of view. > > > > > Focusing the MA on the router (even if there could be multiple access > > > types) reduce the problem space, and this is something that the ISPs > > > do already, except they have proprietary solutions > > > > Well, yes, such a restriction might allows the WG to sidestep some > > discussions. However, from an architectural point of view, I would hope > > that the resulting technology is at the end general enough to be > > applied to other use cases and deployments as well. > > >=20 > Agree with Juergen - don't mind this restriction if it helps the > chartering process, but hope the standards would have wider applicability >=20 > phil >=20 > > > > /js > > > > PS: And to cover some of today's hardware probe based systems, you > > would have to replace 'on the router' with 'on or close to the > > router'. > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From dromasca@avaya.com Wed May 8 05:58:25 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481BF21F92CF for ; Wed, 8 May 2013 05:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y-gK6BvlVsj for ; Wed, 8 May 2013 05:58:19 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 93D8721F91CA for ; Wed, 8 May 2013 05:58:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAH/ZlGHCzI1/2dsb2JhbABNA4JlITbBSIEHFnSCHwEBAQECAQEBAQ8oNAsMAgICAQgNAwEEAQEBChQJBxsMCxQJCAIEAQ0FCBMHh2wGAQugPJ0jBI5hIQULBwYLgk9hA5M2iXOKaIMLgig X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="10259803" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 May 2013 08:58:18 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 May 2013 08:54:41 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Wed, 8 May 2013 08:58:17 -0400 From: "Romascanu, Dan (Dan)" To: "MORTON JR., ALFRED C (AL)" , "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" , "bclaise@cisco.com" Thread-Topic: [lmap] LMAP: situation: Question 4: Measurement Agent device type Thread-Index: AQHOS0cyyDhuleP+3ECj/RRJ5nBnu5j7QIMQ Date: Wed, 8 May 2013 12:58:16 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA16742F@AZ-FFEXMB04.global.avaya.com> References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> <20130507050348.GA56873@elstar.local> <9510D26531EF184D9017DF24659BB87F346DC9A6E5@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 12:58:25 -0000 Hi Al, Can you draft a sentence or two for charter clarification purposes? We'll s= ee if we can get consensus around it and whether it answers Benoit's questi= on.=20 Thanks and Regards, Dan > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > MORTON JR., ALFRED C (AL) > Sent: Tuesday, May 07, 2013 8:20 PM > To: philip.eardley@bt.com; j.schoenwaelder@jacobs-university.de; > bclaise@cisco.com > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent > device type >=20 > I think overlapping measurement systems may be unavoidable. > There's lots of testing to web-based measurement sites today. > When users run tests on-demand, they have some purpose in mind and agree > to the traffic implications, and to the ISP it's just user traffic (as > in no-gaming). >=20 > But the simplest coordination between systems is that they avoid cross- > traffic - and that may mean that user host MAs will not be able to > detect when the router MA is trying to a test, for example, and the > router test would back-off (seeing user traffic). So here I agree with > Phil, listening before (possible during) tests is preferred. >=20 > Al >=20 >=20 > > -----Original Message----- > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > > Of philip.eardley@bt.com > > Sent: Tuesday, May 07, 2013 10:13 AM > > To: j.schoenwaelder@jacobs-university.de; bclaise@cisco.com > > Cc: lmap@ietf.org > > Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent > > device type > > > > > > > > > -----Original Message----- > > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > > > Of Juergen Schoenwaelder > > > Sent: 07 May 2013 06:04 > > > To: Benoit Claise > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent > > > device type > > > > > > On Mon, May 06, 2013 at 11:06:02PM +0100, Benoit Claise wrote: > > > > > > > Let me explain differently, by asking question. > > > > How many MAs do you expect in a branch office? > > > > One on the router? > > > > How many MAs do you expect to have in a home? > > > > One per exit router? > > > > One on my IPAD? > > > > One on my PC? > > > > One on my phone? > > > > Those MAs are somehow coordinated? > > > > If yes, how? > > > > If not, we have 4 times the measurements. > > > > Interesting point. > > > > If all the MAs are under the control of the same measurement system, > > then there is some hope that they can be coordinated. In terms of > > Active Measurement Tasks, the Controller needs to understand that they > > all use the same access connection. I guess this should be possible as > > part of the process when the measurement system deploys the MA > > function onto the device. > > > > However, it's possible that the MAs aren't all under the control of > > the same measurement system. Perhaps the ISP has deployed the MA on > > the exit router, the regulator the MA on the STB, the user the MA on > > the tablet etc. > > I don't think I'd try and coordinate all these MAs. this sounds hard > > (and if the home is connected to 2 access networks, it might be > > impossible to know which network an MA would use). > > Perhaps we simply say it's good practice for the measurement tasks to > > 'listen before talk' (and perhaps have a back-off algorithm, > > especially if the task is long-running or heavy-loading) > > > > > > > > I think the answer will depend on who deploys MAs. For the ISP use > > > case, an MA in the access router (exit router or whatever you call > > > that > > > box) is likely what the ISP needs. If we talk about say TV over IP > > > services, I could see that someone might embed an MA in a TV set > > > (which might do only passive measurements to report characteristics > > > of multi- media streams). If we allow regular users to deploy MAs in > > > order to make independent measurements, I would not be surprised is > > > someone builds an 'app' for popular devices that essentially > includes a MA. > > > But then it is a human user who deploys this 'app', likely he/she > > > knows the consequences what what he/she is doing. > > > > > > > The access options are also important > > > > One my phone/IPAD connected via wireless, that could be OK > > > > One my phone/IPAD connected via 3G, that's not OK with me > > > > > > Although an MA doing passive measurements might still be OK on your > > > 3G link from a bandwidth point of view. > > > > > > > Focusing the MA on the router (even if there could be multiple > > > > access > > > > types) reduce the problem space, and this is something that the > > > > ISPs do already, except they have proprietary solutions > > > > > > Well, yes, such a restriction might allows the WG to sidestep some > > > discussions. However, from an architectural point of view, I would > > > hope that the resulting technology is at the end general enough to > > > be applied to other use cases and deployments as well. > > > > > > > Agree with Juergen - don't mind this restriction if it helps the > > chartering process, but hope the standards would have wider > > applicability > > > > phil > > > > > > > > /js > > > > > > PS: And to cover some of today's hardware probe based systems, you > > > would have to replace 'on the router' with 'on or close to the > > > router'. > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From jason_livingood@cable.comcast.com Wed May 8 14:02:25 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A8021F9057 for ; Wed, 8 May 2013 14:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7ET8Shkj3gU for ; Wed, 8 May 2013 14:02:18 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 9772F21F8FDC for ; Wed, 8 May 2013 14:02:18 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.70462565; Wed, 08 May 2013 15:01:35 -0600 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 8 May 2013 17:02:10 -0400 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.253]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Wed, 8 May 2013 17:02:10 -0400 From: "Livingood, Jason" To: "MORTON JR., ALFRED C (AL)" , "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" , "bclaise@cisco.com" Thread-Topic: [lmap] LMAP: situation: Question 4: Measurement Agent device type Thread-Index: AQHOTC9NYo5JhNVzrkeAAOdw1JzE8Q== Date: Wed, 8 May 2013 21:02:09 +0000 Message-ID: <10229F86C86EB444898E629583FD41718C48B534@PACDCEXMB06.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 21:02:25 -0000 On 5/7/13 1:20 PM, "MORTON JR., ALFRED C (AL)" wrote: >I think overlapping measurement systems may be unavoidable. may be unavoidable --> is unavoidable >There's lots of testing to web-based measurement sites today. >When users run tests on-demand, they have some purpose in mind >and agree to the traffic implications, and to the ISP it's >just user traffic (as in no-gaming). > >But the simplest coordination between systems is that they >avoid cross-traffic - and that may mean that user host MAs >will not be able to detect when the router MA is trying to >a test, for example, and the router test would back-off >(seeing user traffic). So here I agree with Phil, listening >before (possible during) tests is preferred. Quite so. I think since MAs will test a range of protocols we can't just watch for port XX and back off. So the better is to watch for some threshold traffic level which, if exceeded, means no test is run. What may be somewhat more challenging is deciding whether that level is zero traffic (which with background / Internet of things / home automation / background apps could be increasingly unlikely) or some low single digit % of the provisioned rate for an end user (requiring advance knowledge of this and/or standardized access to discover it) or some small # of kbps. Or it is configurable for every measurement system. Perhaps one of the SamKnows guys can comment on how exactly their listener / test run decision logic works... In any case, it is good for us to assume that there will normally be multiple overlapping test administrative domains (for lack of a better description) within a given logical network such as a home network. - Jason From dengguangqing@cnnic.cn Wed May 8 20:28:30 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D4021F8FE9 for ; Wed, 8 May 2013 20:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUDAlfPNioIX for ; Wed, 8 May 2013 20:28:26 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 9402621F9104 for ; Wed, 8 May 2013 20:28:23 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 09 May 2013 11:28:15 +0800 Date: Thu, 9 May 2013 11:28:14 +0800 From: "Guangqing Deng" To: =?gb2312?B?TGl2aW5nb29kLCBKYXNvbg==?= References: <10229F86C86EB444898E629583FD41718C48B534@PACDCEXMB06.cable.comcast.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201305091128144271806@cnnic.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 03:28:31 -0000 Pk9uIDUvNy8xMyAxOjIwIFBNLCAiTU9SVE9OIEpSLiwgQUxGUkVEIEMgKEFMKSIgPGFjbW9ydG9u QGF0dC5jb20+IHdyb3RlOg0KPg0KPj5JIHRoaW5rIG92ZXJsYXBwaW5nIG1lYXN1cmVtZW50IHN5 c3RlbXMgbWF5IGJlIHVuYXZvaWRhYmxlLg0KPg0KPm1heSBiZSB1bmF2b2lkYWJsZSAtLT4gaXMg dW5hdm9pZGFibGUNClRoYXQncyBteSBwb2ludCB0b28uDQo+DQo+PlRoZXJlJ3MgbG90cyBvZiB0 ZXN0aW5nIHRvIHdlYi1iYXNlZCBtZWFzdXJlbWVudCBzaXRlcyB0b2RheS4NCj4+V2hlbiB1c2Vy cyBydW4gdGVzdHMgb24tZGVtYW5kLCB0aGV5IGhhdmUgc29tZSBwdXJwb3NlIGluIG1pbmQNCj4+ YW5kIGFncmVlIHRvIHRoZSB0cmFmZmljIGltcGxpY2F0aW9ucywgYW5kIHRvIHRoZSBJU1AgaXQn cw0KPj5qdXN0IHVzZXIgdHJhZmZpYyAoYXMgaW4gbm8tZ2FtaW5nKS4NCj4+DQo+PkJ1dCB0aGUg c2ltcGxlc3QgY29vcmRpbmF0aW9uIGJldHdlZW4gc3lzdGVtcyBpcyB0aGF0IHRoZXkNCj4+YXZv aWQgY3Jvc3MtdHJhZmZpYyAtIGFuZCB0aGF0IG1heSBtZWFuIHRoYXQgdXNlciBob3N0IE1Bcw0K Pj53aWxsIG5vdCBiZSBhYmxlIHRvIGRldGVjdCB3aGVuIHRoZSByb3V0ZXIgTUEgaXMgdHJ5aW5n IHRvDQo+PmEgdGVzdCwgZm9yIGV4YW1wbGUsIGFuZCB0aGUgcm91dGVyIHRlc3Qgd291bGQgYmFj ay1vZmYNCj4+KHNlZWluZyB1c2VyIHRyYWZmaWMpLiBTbyBoZXJlIEkgYWdyZWUgd2l0aCBQaGls LCBsaXN0ZW5pbmcNCj4+YmVmb3JlIChwb3NzaWJsZSBkdXJpbmcpIHRlc3RzIGlzIHByZWZlcnJl ZC4NCj4NCj5RdWl0ZSBzby4gSSB0aGluayBzaW5jZSBNQXMgd2lsbCB0ZXN0IGEgcmFuZ2Ugb2Yg cHJvdG9jb2xzIHdlIGNhbid0IGp1c3QNCj53YXRjaCBmb3IgcG9ydCBYWCBhbmQgYmFjayBvZmYu IFNvIHRoZSBiZXR0ZXIgaXMgdG8gd2F0Y2ggZm9yIHNvbWUNCj50aHJlc2hvbGQgdHJhZmZpYyBs ZXZlbCB3aGljaCwgaWYgZXhjZWVkZWQsIG1lYW5zIG5vIHRlc3QgaXMgcnVuLg0KPg0KVG90YWxs eSBhZ3JlZSB3aXRoIKGwbGlzdGVuaW5nIGJlZm9yZSB0YWxraW5nobEuIEJlc2lkZXMgYmFja2dy b3VuZCB0cmFmZmljLCANCmZvciB0aG9zZSBtb2JpbGUgZGV2aWNlcyBsaWtlIG1vYmlsZSBwaG9u ZSBhbmQgSVBBRCwgdGhlIGN1cnJlbnQgbGV2ZWwgb2YgDQpiYXR0ZXJ5IGVuZXJneSBtYXkgYWxz byBuZWVkIHRvIGJlIGRldGVjdGVkIGJlZm9yZSBtZWFzdXJlbWVudC4NCg0KPldoYXQgbWF5IGJl IHNvbWV3aGF0IG1vcmUgY2hhbGxlbmdpbmcgaXMgZGVjaWRpbmcgd2hldGhlciB0aGF0IGxldmVs IGlzDQo+emVybyB0cmFmZmljICh3aGljaCB3aXRoIGJhY2tncm91bmQgLyBJbnRlcm5ldCBvZiB0 aGluZ3MgLyBob21lIGF1dG9tYXRpb24NCj4vIGJhY2tncm91bmQgYXBwcyBjb3VsZCBiZSBpbmNy ZWFzaW5nbHkgdW5saWtlbHkpIG9yIHNvbWUgbG93IHNpbmdsZSBkaWdpdA0KPiUgb2YgdGhlIHBy b3Zpc2lvbmVkIHJhdGUgZm9yIGFuIGVuZCB1c2VyIChyZXF1aXJpbmcgYWR2YW5jZSBrbm93bGVk Z2Ugb2YNCj50aGlzIGFuZC9vciBzdGFuZGFyZGl6ZWQgYWNjZXNzIHRvIGRpc2NvdmVyIGl0KSBv ciBzb21lIHNtYWxsICMgb2Yga2Jwcy4NCj5PciBpdCBpcyBjb25maWd1cmFibGUgZm9yIGV2ZXJ5 IG1lYXN1cmVtZW50IHN5c3RlbS4gUGVyaGFwcyBvbmUgb2YgdGhlDQo+U2FtS25vd3MgZ3V5cyBj YW4gY29tbWVudCBvbiBob3cgZXhhY3RseSB0aGVpciBsaXN0ZW5lciAvIHRlc3QgcnVuDQo+ZGVj aXNpb24gbG9naWMgd29ya3MuLi4NCj4NCj5JbiBhbnkgY2FzZSwgaXQgaXMgZ29vZCBmb3IgdXMg dG8gYXNzdW1lIHRoYXQgdGhlcmUgd2lsbCBub3JtYWxseSBiZQ0KPm11bHRpcGxlIG92ZXJsYXBw aW5nIHRlc3QgYWRtaW5pc3RyYXRpdmUgZG9tYWlucyAoZm9yIGxhY2sgb2YgYSBiZXR0ZXINCj5k ZXNjcmlwdGlvbikgd2l0aGluIGEgZ2l2ZW4gbG9naWNhbCBuZXR3b3JrIHN1Y2ggYXMgYSBob21l IG5ldHdvcmsuDQo+DQo+LSBKYXNvbg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+bG1hcCBtYWlsaW5nIGxpc3QNCj5sbWFwQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFwDQoNCkd1YW5ncWluZyBE ZW5nDQpDTk5JQyA= From mattmathis@google.com Sun May 12 16:49:05 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04021F8D2E for ; Sun, 12 May 2013 16:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.777 X-Spam-Level: X-Spam-Status: No, score=-100.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQr7uwAoK+Q6 for ; Sun, 12 May 2013 16:49:04 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id A297F21F8C40 for ; Sun, 12 May 2013 16:49:04 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id h37so1636571iak.38 for ; Sun, 12 May 2013 16:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=ZGysYkaUiEvwTHkYjY9mkTXVUy+Mhk5RCancQrutT38=; b=o7ILW9fq6YB617pck3MfYtTUAqrUI99+4XYq40E7mrqZ7kkniUwsFQWSPzE1kFleho WEQ3JtdAHCibk/QfCKFzByoWk7130ru3yRTtEAIx/69VzKBadvhIX3RHNYmDa6iGFM+r dQmz+ct4/jOtC+edfsQyVZt+JWgNeFLLGH5ZJv85c7VO5HMghhXseyc/VaPNl82lMrqt 0s2JxS1XrYkyMwAwgtZxsnxXSMsWopC9hWFTE7ttWUQtr3PNgy6b2rWdoxXRjN8ziV62 Il1RlwpfTTCcvJGM2YsBueS84GkRj2DzQIdhXbfvPMTWHFtpAzhPVntq+SkMs+zj4AqW yGxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=ZGysYkaUiEvwTHkYjY9mkTXVUy+Mhk5RCancQrutT38=; b=EyeeNXbIqzoKaDCDTWAFRwsP/TB9txnwQEeDHE/pDr+DiO8v5JsamFqcjNV15CS1SM IlAz7GGgkValM5MWhPRRmmsW2uACLQSW/y9BUTMzaGw/6w13/CDyE5tBkakXjFe28Iyb AcVgucIgdc255bk8xhi3bViiHQwGrRMROhqByH4nuoVpgfEQDCEHi2QStnZTHcIiCXaF uuxSwkjff9FMOKWuKtsSlatoogx9hXkRRJrEQ988K864c52K8LR5lM3CFHq6hhqRu/8p 2qEddM2JDYqOGxE/nvqGHtc5NJp2mFO6jTzsBEsvqZw9KfQHQjWx2cZJVjVDIyJeinuW 2S5w== MIME-Version: 1.0 X-Received: by 10.50.78.34 with SMTP id y2mr8683611igw.50.1368402543989; Sun, 12 May 2013 16:49:03 -0700 (PDT) Received: by 10.64.227.227 with HTTP; Sun, 12 May 2013 16:49:03 -0700 (PDT) Date: Sun, 12 May 2013 16:49:03 -0700 Message-ID: From: Matt Mathis To: "EARDLEY, Phil" Content-Type: multipart/alternative; boundary=089e01160a1a8b7a5704dc8e0b47 X-Gm-Message-State: ALoCoQnlhjyG3/golJ5PYswgAOYhLgEiW1NdY/EHLnyHLGj7PhqhsZFixXN511y7833dT8O2nUS/HamWnvMZZDJq5JEJrRp83Vixpy4rODtbpIhcyel6HHJz24uwUh2zve/u3GPU0urjEalKV40mXsc5C86swhqy0qM/Srnm+jtGtAcZR/2Hg6fzy5VDkkfEMlk4HtDZbzHb Cc: "lmap@ietf.org" Subject: [lmap] Missing concept from draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 23:49:05 -0000 --089e01160a1a8b7a5704dc8e0b47 Content-Type: text/plain; charset=ISO-8859-1 Most of the terminology in this draft defined by routing and addressing concepts. For measurement, it is also important to have terminology to describe traffic aggregation. Especially important is over which subpaths might one customer's traffic be subject to resource contention with other customers? I would like to have precise but technology independent terms for the boundary between shared and unshared access resources. Note that for many technologies (mobile service, DOCSIS) this is very close to the service demarc at the customer. For others, such as FTTH and DSL it typically occurs in centralized location. The measurement problems on either side of this boundary are extremely different, and we need to be able to unambiguously make this dichotomy. I use "unshared access", "shared access", and "sharing point." Note that for many technologies the sharing point is L2 or lower, so there might not a natural way to connect a MP at the sharing point. There is also the risk that addressing and routing are going to become progressively less relevant as more and more of the network becomes virtualized through such technologies as software defined networks. I consider ownership (responsibility), traffic aggregation and resource contention to be far more important than addressing. Also, "Destination host" is a rather odd choice for a content provider. Perhaps "core service provider." Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Thu, May 2, 2013 at 2:52 AM, wrote: > I updated the draft > http://tools.ietf.org/html/draft-eardley-lmap-terminology > Thank-you for all the comments! > > (the draft is a possible starting point for terminology for the > prospective lmap wg) > > Best wishes > phil > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 02 May 2013 09:40 > To: Al Morton; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; Al > C.Morton; Marcelo Bagnulo > Subject: New Version Notification for draft-eardley-lmap-terminology-01.txt > > > A new version of I-D, draft-eardley-lmap-terminology-01.txt > has been successfully submitted by Philip Eardley and posted to the IETF > repository. > > Filename: draft-eardley-lmap-terminology > Revision: 01 > Title: Terminology for Large MeAsurement Platforms (LMAP) > Creation date: 2013-05-02 > Group: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-eardley-lmap-terminology-01.txt > Status: > http://datatracker.ietf.org/doc/draft-eardley-lmap-terminology > Htmlized: > http://tools.ietf.org/html/draft-eardley-lmap-terminology-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-eardley-lmap-terminology-01 > > Abstract: > This documents defines terminology for Large Scale Measurement > Platforms. > > > > > The IETF Secretariat > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > --089e01160a1a8b7a5704dc8e0b47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Most of the terminology in this draft defined by routing a= nd addressing concepts. =A0 For measurement, it is also important to have t= erminology to describe traffic aggregation. =A0Especially important is over= which subpaths might one customer's traffic be subject to resource con= tention with other customers?

I would like to have precise but technology independent term= s for the boundary between shared and unshared access resources. =A0 Note t= hat for many technologies (mobile service, DOCSIS) this is very close to th= e service demarc at the customer. =A0For others, such as FTTH and DSL it ty= pically occurs in centralized location.

The measurement problems on either side of this b= oundary are extremely different, and we need to be able to unambiguously ma= ke this dichotomy.

I use "unshare= d access", "shared access", and "sharing point." = =A0 Note that for many technologies the sharing point is L2 or lower, so th= ere might not a natural way to connect a MP at the sharing point.

There is also the risk that addressing and = routing are going to become progressively less relevant as more and more of= the network becomes virtualized through such technologies as software defi= ned networks. =A0 =A0I consider ownership (responsibility), traffic aggrega= tion and resource contention to be far more important than addressing.

Also, "Destination host" is a rather od= d choice for a content provider. =A0 Perhaps "core service provider.&q= uot;

Thanks,
--MM--
The best way to predict the future is to create= it. =A0- Alan Kay

Privacy matters! =A0We know from recent events th= at people are using our services to speak in defiance of unjust governments= . =A0 We treat privacy and security as matters of life and death, because f= or some users, they are.


On Thu, May 2, 2013 at 2:52 AM, <p= hilip.eardley@bt.com> wrote:
http://tools.ietf.org/html/draft-eardley-lmap-= terminology
Thank-you for all the comments!

(the draft is a possible starting point for terminology for the prospective= lmap wg)

Best wishes
phil

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: 02 May 2013 09:40
To: Al Morton; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; Al C.Mo= rton; Marcelo Bagnulo
Subject: New Version Notification for draft-eardley-lmap-terminology-01.txt=


A new version of I-D, draft-eardley-lmap-terminology-01.txt
has been successfully submitted by Philip Eardley and posted to the IETF re= pository.

Filename: =A0 =A0 =A0 =A0draft-eardley-lmap-terminology
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Terminology for Large MeAsurement Platforms (LMA= P)
Creation date: =A0 2013-05-02
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 10
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.o= rg/internet-drafts/draft-eardley-lmap-terminology-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/do= c/draft-eardley-lmap-terminology
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-e= ardley-lmap-terminology-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rf= cdiff?url2=3Ddraft-eardley-lmap-terminology-01

Abstract:
=A0 =A0This documents defines terminology for Large Scale Measurement
=A0 =A0Platforms.




The IETF Secretariat

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

--089e01160a1a8b7a5704dc8e0b47-- From bclaise@cisco.com Mon May 13 09:21:06 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192D221F941F for ; Mon, 13 May 2013 09:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.061 X-Spam-Level: X-Spam-Status: No, score=-10.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUFcTehqiW2m for ; Mon, 13 May 2013 09:21:01 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C44AD21F93EE for ; Mon, 13 May 2013 09:21:00 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4DGKtba008588; Mon, 13 May 2013 18:20:55 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4DGKG44001959; Mon, 13 May 2013 18:20:26 +0200 (CEST) Message-ID: <519112C0.2080809@cisco.com> Date: Mon, 13 May 2013 18:20:16 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "lmap@ietf.org" , Lemon Ted References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> <20130507050348.GA56873@elstar.local> In-Reply-To: <20130507050348.GA56873@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 16:21:06 -0000 On 7/05/2013 07:03, Juergen Schoenwaelder wrote: > On Mon, May 06, 2013 at 11:06:02PM +0100, Benoit Claise wrote: > >> Let me explain differently, by asking question. >> How many MAs do you expect in a branch office? >> One on the router? >> How many MAs do you expect to have in a home? >> One per exit router? >> One on my IPAD? >> One on my PC? >> One on my phone? >> Those MAs are somehow coordinated? >> If yes, how? >> If not, we have 4 times the measurements. > I think the answer will depend on who deploys MAs. For the ISP use > case, an MA in the access router (exit router or whatever you call > that box) is likely what the ISP needs. If we talk about say TV over > IP services, I could see that someone might embed an MA in a TV set > (which might do only passive measurements to report characteristics of > multi-media streams). If we allow regular users to deploy MAs in order > to make independent measurements, I would not be surprised is someone > builds an 'app' for popular devices that essentially includes a MA. > But then it is a human user who deploys this 'app', likely he/she > knows the consequences what what he/she is doing. Yes. What I don't want is the ISP trying to install MAs on all my home devices without so sort of coordination. I should have make that clear. Actually, I don't want an ISP to install MAs on any of my devices. However, if I chose to, then yes, I want to be able to install MA on any of my devices. In that case, we have some more questions: - what about service parameters, which my devices don't know about? Don't care, manual introduction in the MA, or automatic discovery? - what about multiple interface (IPv4, IPv6, 3G). This is the MIF WG issue - these should be the same tests as my ISP, so that I could compare. How? Regarding measurement coordinations on my devices, I agree that this might unavoidable > >> The access options are also important >> One my phone/IPAD connected via wireless, that could be OK >> One my phone/IPAD connected via 3G, that's not OK with me > Although an MA doing passive measurements might still be OK on your 3G > link from a bandwidth point of view. For active monitoring, there is also a connection with the MIF WG. I guess we want to know the access type (IPv4, IPv6, 3G) ... even if the measurement test always takes the default/best path, as this can change over the time. Regards, Benoit > >> Focusing the MA on the router (even if there could be multiple >> access types) reduce the problem space, and this is something that >> the ISPs do already, except they have proprietary solutions > Well, yes, such a restriction might allows the WG to sidestep some > discussions. However, from an architectural point of view, I would > hope that the resulting technology is at the end general enough to be > applied to other use cases and deployments as well. > > /js > > PS: And to cover some of today's hardware probe based systems, you > would have to replace 'on the router' with 'on or close to the > router'. > From bclaise@cisco.com Mon May 13 09:39:34 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6E421F8F4D for ; Mon, 13 May 2013 09:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.103 X-Spam-Level: X-Spam-Status: No, score=-10.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFGqRIYevWCd for ; Mon, 13 May 2013 09:39:30 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEAF21F8EC1 for ; Mon, 13 May 2013 09:39:29 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4DGdJ3J010203; Mon, 13 May 2013 18:39:19 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4DGcBTE014801; Mon, 13 May 2013 18:38:21 +0200 (CEST) Message-ID: <519116F3.1010503@cisco.com> Date: Mon, 13 May 2013 18:38:11 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: philip.eardley@bt.com References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> <51867E8B.5060502@cisco.com> <9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lmap@ietf.org, trevor.burbridge@bt.com, j.schoenwaelder@jacobs-university.de, Michael.K.Bugenhagen@centurylink.com, jason.weil@twcable.com, shane@castlepoint.net, bs7652@att.com Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 16:39:34 -0000 On 7/05/2013 16:41, philip.eardley@bt.com wrote: >>> So in terms of Benoit's questions: >>> - The Internet Service Provider use case is in scope, assuming that >>> the ISP controls the functions for the Measurement Agent, Controller >>> and Collector >>> - The regulator use case is in scope, assuming that the regulator >>> controls the functions for the Measurement Agent, Controller and >>> Collector >> I'm wondering whether the previous two points are not incompatible? >> Most ISPs have, or will have, a type of LMAP architecture anyway. When >> I call my provider (home network), they can already do the type of LMAP >> tests on my router. So what use case is left of the regulator (knowing >> the assumption that a MA is under the administration of a single >> entity)? >> > Not sure I get your point - anyway, I don't think they're incompatible. Let me more explicit. Example: A home, with a single router and a single PC. ISP use case: the MA is on the router, under ISP supervision. Then what's left for the regulator use case? - The ideal regulator situation is to get a MA on the router. But the router is under the ISP supervision in this case. That breaks the assumption that a MA is under a single supervision. - So it has to be on my personal device? Do you envision the regulator forcing me to install something on my personal device because the router is under the ISP supervision? - Or do you envision the regulator forcing me to install an extra probe/MA box in my network? - Or, because the router is taken, and I don't want to install anything else in my network, the regulator should get the test reports from the ISP? Regards, Benoit > > The MAs, controller and collector(s) are all under common control (single measurement system). > >From a commercial point of view this looks the same as existing systems - either samknows style measurement systems operated on behalf of a regulator - or (as you say) where an ISP has measurement functions in a router. > Lmap would enable this sort of system to scale better, allow multi-vendor operation, etc > > Thanks > phil > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > From j.schoenwaelder@jacobs-university.de Mon May 13 10:52:41 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEA721F90EE for ; Mon, 13 May 2013 10:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhRxyTyJ-vQS for ; Mon, 13 May 2013 10:52:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 531F321F915B for ; Mon, 13 May 2013 10:52:36 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6608D20C22; Mon, 13 May 2013 19:52:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eq3qbgqVWNxu; Mon, 13 May 2013 19:52:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7E1920C20; Mon, 13 May 2013 19:52:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B3ECB2636F91; Mon, 13 May 2013 19:52:32 +0200 (CEST) Date: Mon, 13 May 2013 19:52:31 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20130513175230.GB10091@elstar.local> Mail-Followup-To: Benoit Claise , "lmap@ietf.org" , Lemon Ted References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> <20130507050348.GA56873@elstar.local> <519112C0.2080809@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519112C0.2080809@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Lemon Ted , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:52:41 -0000 On Mon, May 13, 2013 at 06:20:16PM +0200, Benoit Claise wrote: > What I don't want is the ISP trying to install MAs on all my home > devices without so sort of coordination. I should have make that > clear. Actually, I don't want an ISP to install MAs on any of my > devices. If your ISP can install software on your private devices, I agree you have a serious problem. ;-) > However, if I chose to, then yes, I want to be able to install MA on > any of my devices. > In that case, we have some more questions: > - what about service parameters, which my devices don't know about? > Don't care, manual introduction in the MA, or automatic discovery? In the general case, I would expect that your device would not be able to discover any service parameters unless you have provided the credentials to the device to access a service parameter service of your ISP (in which case you have implicitely given your device the permission to do so). > - what about multiple interface (IPv4, IPv6, 3G). This is the MIF WG issue Unclear question - skipped. > - these should be the same tests as my ISP, so that I could compare. How? The idea I think is that test may be standardized (in IPPM) including the set of parameters that can be set. So if you can get all the details, you should be able to compare results (minus variation introduced by using different platforms and perhaps slightly different MA locations). I guess I do not really understand the 'how' question either. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Ted.Lemon@nominum.com Mon May 13 12:05:55 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF03521F947C for ; Mon, 13 May 2013 12:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.339 X-Spam-Level: X-Spam-Status: No, score=-106.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMB4bV5TLdKD for ; Mon, 13 May 2013 12:05:49 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id F1ED521F88B4 for ; Mon, 13 May 2013 12:05:48 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUZE5jOuJQg66lUChe7928ksritUyNKa4@postini.com; Mon, 13 May 2013 12:05:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 675171B815F for ; Mon, 13 May 2013 12:05:48 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5CB7119005D; Mon, 13 May 2013 12:05:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 13 May 2013 12:05:48 -0700 From: Ted Lemon To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP: situation: Question 4: Measurement Agent device type Thread-Index: AQHOT/Xdy0KURQg4wU6Hlns4VHBwHJkD2rSAgAAUeYA= Date: Mon, 13 May 2013 19:05:48 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751807ED@mbx-01.win.nominum.com> References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> <20130507050348.GA56873@elstar.local> <519112C0.2080809@cisco.com> <20130513175230.GB10091@elstar.local> In-Reply-To: <20130513175230.GB10091@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <05286955B722F54095B67F85039AA7A6@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:05:55 -0000 On May 13, 2013, at 1:52 PM, Juergen Schoenwaelder wrote: >> - what about multiple interface (IPv4, IPv6, 3G). This is the MIF WG iss= ue > Unclear question - skipped. Suppose you have a device with a 3G and a Wifi interface, and you want to d= o measurement from that device. Does the measuring application just blind= ly connect, and then ask the stack which way the flow is going? That woul= d be valid. Does it try to dictate which way the flow will go? Also val= id. Does it attempt to establish a flow over each interface? Also valid= . Does it have a UI to allow the user to exclude some interfaces from mea= surement? Etc. From acmorton@att.com Mon May 13 12:34:03 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D714221F8A7B for ; Mon, 13 May 2013 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kyfu-rHl6zEv for ; Mon, 13 May 2013 12:33:59 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0379321F8E74 for ; Mon, 13 May 2013 12:33:59 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 5D55612043C; Mon, 13 May 2013 15:33:57 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id E0B63E297E; Mon, 13 May 2013 15:33:41 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Mon, 13 May 2013 15:33:57 -0400 From: "MORTON JR., ALFRED C (AL)" To: Juergen Schoenwaelder , Benoit Claise Date: Mon, 13 May 2013 15:33:57 -0400 Thread-Topic: [lmap] LMAP: situation: Question 4: Measurement Agent device type Thread-Index: Ac5QArOcruCwfbcLTNGXPMMhPoqcEAACxvug Message-ID: References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> <20130507050348.GA56873@elstar.local> <519112C0.2080809@cisco.com> <20130513175230.GB10091@elstar.local> In-Reply-To: <20130513175230.GB10091@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 Cc: Lemon Ted , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:34:03 -0000 > From: Juergen Schoenwaelder > > > On Mon, May 13, 2013 at 06:20:16PM +0200, Benoit Claise wrote: > > - these should be the same tests as my ISP, so that I could compare. Ho= w? >=20 > The idea I think is that test may be standardized (in IPPM) including > the set of parameters that can be set. So if you can get all the > details, you should be able to compare results (minus variation > introduced by using different platforms and perhaps slightly different > MA locations). I guess I do not really understand the 'how' question > either. >=20 > /js All LMAP MAs use the Control and Reporting Protocols which should take adva= ntage of the new IPPM metric registry for metric selection, and with by-product t= hat the measurement implementation process can simplified when only registered metr= ics are needed.=20 MAs running on a user's unknown device introduce some variability as=20 Juergen said, but that variation and the specific interface connectivity ar= e=20 likely to be key aspects of the user's performance=20 (and why the user requested and installed an MA in the first place). Al > > -----Original Message----- > Sent: Monday, May 13, 2013 1:53 PM > To: Benoit Claise > Cc: Lemon Ted; lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device > type >=20 >=20 > > What I don't want is the ISP trying to install MAs on all my home > > devices without so sort of coordination. I should have make that > > clear. Actually, I don't want an ISP to install MAs on any of my > > devices. >=20 > If your ISP can install software on your private devices, I agree you > have a serious problem. ;-) >=20 > > However, if I chose to, then yes, I want to be able to install MA on > > any of my devices. > > In that case, we have some more questions: > > - what about service parameters, which my devices don't know about? > > Don't care, manual introduction in the MA, or automatic discovery? >=20 > In the general case, I would expect that your device would not be able > to discover any service parameters unless you have provided the > credentials to the device to access a service parameter service of > your ISP (in which case you have implicitely given your device the > permission to do so). >=20 > > - what about multiple interface (IPv4, IPv6, 3G). This is the MIF WG > issue >=20 > Unclear question - skipped. >=20 > > - these should be the same tests as my ISP, so that I could compare. > How? >=20 > The idea I think is that test may be standardized (in IPPM) including > the set of parameters that can be set. So if you can get all the > details, you should be able to compare results (minus variation > introduced by using different platforms and perhaps slightly different > MA locations). I guess I do not really understand the 'how' question > either. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From acmorton@att.com Mon May 13 13:17:13 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B888521F93FF for ; Mon, 13 May 2013 13:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwHLuKzVqmjm for ; Mon, 13 May 2013 13:17:08 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id C056F21F93FC for ; Mon, 13 May 2013 13:17:08 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 5473E1203D4; Mon, 13 May 2013 16:17:07 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id 5DEFDEF8F2; Mon, 13 May 2013 16:17:08 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Mon, 13 May 2013 16:17:08 -0400 From: "MORTON JR., ALFRED C (AL)" To: Benoit Claise , "philip.eardley@bt.com" Date: Mon, 13 May 2013 16:17:07 -0400 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac5P+H2h/hE/rGHTR9qJLebNGkMSYAAGitFg Message-ID: References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> <51867E8B.5060502@cisco.com> <9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net> <519116F3.1010503@cisco.com> In-Reply-To: <519116F3.1010503@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" , "trevor.burbridge@bt.com" , "j.schoenwaelder@jacobs-university.de" , "Michael.K.Bugenhagen@centurylink.com" , "jason.weil@twcable.com" , "shane@castlepoint.net" , "STARK, BARBARA H" Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 20:17:13 -0000 Hi Benoit, I appreciate that one organization's implementation of LMAP may constrain another's, especially if they both intend to measure almost exactly the same portion of the network. An alternative when the ISP is using an MA on their own gateway/router is that the regulator asks users to volunteer to make measurements, and that's been done many times already with a "white-box". It seems this could be extended to an embedded client with reasonable=20 qualifications, especially connectivity, listening for competing user traff= ic=20 (that's simple in your single case with a single PC) and perhaps others. An environment with some overlapping measurement covera= ge seems very likely (to several people on the list). > - Or, because the router is taken, and I don't want to install anything > else in my network, the regulator should get the test reports from the > ISP? I suspect that the agreed measurements and desired results, collected at la= rge scale,=20 and reported in the way a regulator wants, would go a long way to support i= nformation gathering without the complexity of maintaining a measurement system.=20 Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Benoit Claise > Sent: Monday, May 13, 2013 12:38 PM > To: philip.eardley@bt.com > Cc: lmap@ietf.org; trevor.burbridge@bt.com; j.schoenwaelder@jacobs- > university.de; Michael.K.Bugenhagen@centurylink.com; > jason.weil@twcable.com; shane@castlepoint.net; STARK, BARBARA H > Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >=20 > On 7/05/2013 16:41, philip.eardley@bt.com wrote: > >>> So in terms of Benoit's questions: > >>> - The Internet Service Provider use case is in scope, assuming that > >>> the ISP controls the functions for the Measurement Agent, Controller > >>> and Collector > >>> - The regulator use case is in scope, assuming that the regulator > >>> controls the functions for the Measurement Agent, Controller and > >>> Collector > >> I'm wondering whether the previous two points are not incompatible? > >> Most ISPs have, or will have, a type of LMAP architecture anyway. When > >> I call my provider (home network), they can already do the type of LMA= P > >> tests on my router. So what use case is left of the regulator (knowing > >> the assumption that a MA is under the administration of a single > >> entity)? > >> > > Not sure I get your point - anyway, I don't think they're incompatible. > Let me more explicit. > Example: A home, with a single router and a single PC. > ISP use case: the MA is on the router, under ISP supervision. >=20 > Then what's left for the regulator use case? > - The ideal regulator situation is to get a MA on the router. But the > router is under the ISP supervision in this case. That breaks the > assumption that a MA is under a single supervision. > - So it has to be on my personal device? Do you envision the regulator > forcing me to install something on my personal device because the router > is under the ISP supervision? > - Or do you envision the regulator forcing me to install an extra > probe/MA box in my network? > - Or, because the router is taken, and I don't want to install anything > else in my network, the regulator should get the test reports from the > ISP? >=20 > Regards, Benoit >=20 > > > > The MAs, controller and collector(s) are all under common control > (single measurement system). > > >From a commercial point of view this looks the same as existing system= s > - either samknows style measurement systems operated on behalf of a > regulator - or (as you say) where an ISP has measurement functions in a > router. > > Lmap would enable this sort of system to scale better, allow multi- > vendor operation, etc > > > > Thanks > > phil > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > > > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Mon May 13 13:47:52 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A9B21F947C for ; Mon, 13 May 2013 13:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW7es8nsdUzk for ; Mon, 13 May 2013 13:47:45 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3C121F9003 for ; Mon, 13 May 2013 13:47:45 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 17151915.2aaada616940.344745.00-535.912132.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 13 May 2013 20:47:45 +0000 (UTC) X-MXL-Hash: 51915171593ff92e-f4d405aba8f367045c5c560ff6dd0b3599769590 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 07151915.0.344736.00-475.912076.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 13 May 2013 20:47:44 +0000 (UTC) X-MXL-Hash: 519151705c0ec1b5-7bebbb4d3b7975582454b476033e57ab85b0ce92 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4DKlhPE012608; Mon, 13 May 2013 16:47:44 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4DKlahZ012520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 May 2013 16:47:39 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by alpi132.aldc.att.com (RSA Interceptor); Mon, 13 May 2013 20:47:21 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0342.003; Mon, 13 May 2013 16:47:21 -0400 From: "STARK, BARBARA H" To: Benoit Claise , "lmap@ietf.org" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/WwAxIzsAAAbJ87AAAbV5gAACcgTQAHG+owAAC+CtIAAUgUqAAATfrAAAF3e0gAABF0BQAABcvnAACh7OAAAAWduAAACOAgAAAG5FAAAAgJiAAAq+KYAAAHv6gACCz4gAAy+vL4AAYlbFAAEx11KAAAED4hA= Date: Mon, 13 May 2013 20:47:20 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302B0F91@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> <51867E8B.5060502@cisco.com> <9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net> <519116F3.1010503@cisco.com> In-Reply-To: <519116F3.1010503@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.59.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=PYlIcFdd c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=BGtaYnrquNMA:10 a=QFZubNyoG38A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16L39IA0IFsA:10 a=QUwjco8FLKG7krCkQ-MA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 20:47:52 -0000 > Example: A home, with a single router and a single PC. > ISP use case: the MA is on the router, under ISP supervision. >=20 > Then what's left for the regulator use case? > - The ideal regulator situation is to get a MA on the router. But the rou= ter is > under the ISP supervision in this case. That breaks the assumption that a= MA > is under a single supervision. I disagree that this breaks that assumption. The regulator negotiates (out = of band) with the ISP as to what measurements get run, measurement peers, e= tc. The ISP manages the router, manages running of the measurements, and co= llects the data. The ISP then provides the regulator with the agreed-upon d= ata (which will have been associated with network parameters and scrubbed f= or privacy, as deemed appropriate). > - So it has to be on my personal device? Do you envision the regulator > forcing me to install something on my personal device because the router = is > under the ISP supervision? > - Or do you envision the regulator forcing me to install an extra probe/M= A > box in my network? Forcing is a harsh word. I'm only aware of programs involving voluntary par= ticipation, to date. If you wish to participate, then to do so, you may fin= d (in the case where the ISP router doesn't support the regulator-desired M= A function) that you are required to have the extra box or install somethin= g on a personal device. If you don't want to do this, don't volunteer to pa= rticipate. > - Or, because the router is taken, and I don't want to install anything e= lse in > my network, the regulator should get the test reports from the ISP? What's wrong with the regulator getting test reports from the ISP? It appea= rs to me that this is exactly what some regulators *want* to do. That is, i= t seems that some regulators would prefer to get the data from the ISP. If = that isn't possible (ISP doesn't provide a router, router is unmanaged, rou= ter is too old and can't be updated to support the desired measurements, et= c.), then there needs to also be the possibility of the 3rd party MA, with = control and data collection done by that same 3rd party (which could be the= regulator, but more likely is someone the regulator contracted with -- but= all parts under one operational domain). And if the router can't do the ne= eded measurements and you don't want to install anything, then you don't pa= rticipate in the regulatory measurement collection program. 3rd party regulator MAs (in separate boxes or personal device apps) are muc= h more about the case where the router can't do the measurements, than they= are about the regulator not wanting or not being able to get measurements = that an ISP has collected from an ISP router. [Note: Many people don't have= a router provided or managed by the ISP. That includes me. Neither of my 2= ISPs offers me a router.] Barbara From j.schoenwaelder@jacobs-university.de Mon May 13 13:53:21 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB721F941F for ; Mon, 13 May 2013 13:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZkZXdbBC9oX for ; Mon, 13 May 2013 13:53:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CE23021F93EE for ; Mon, 13 May 2013 13:53:15 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0227F20C19; Mon, 13 May 2013 22:53:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3g0MTUW5542A; Mon, 13 May 2013 22:53:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7AE1E20C0B; Mon, 13 May 2013 22:53:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1EE1A26376AA; Mon, 13 May 2013 22:53:10 +0200 (CEST) Date: Mon, 13 May 2013 22:53:10 +0200 From: Juergen Schoenwaelder To: Ted Lemon Message-ID: <20130513205308.GA10839@elstar.local> Mail-Followup-To: Ted Lemon , Benoit Claise , "lmap@ietf.org" References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> <20130507050348.GA56873@elstar.local> <519112C0.2080809@cisco.com> <20130513175230.GB10091@elstar.local> <8D23D4052ABE7A4490E77B1A012B6307751807ED@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751807ED@mbx-01.win.nominum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 20:53:22 -0000 On Mon, May 13, 2013 at 07:05:48PM +0000, Ted Lemon wrote: > On May 13, 2013, at 1:52 PM, Juergen Schoenwaelder wrote: > >> - what about multiple interface (IPv4, IPv6, 3G). This is the MIF WG issue > > Unclear question - skipped. > > Suppose you have a device with a 3G and a Wifi interface, and you want to do measurement from that device. Does the measuring application just blindly connect, and then ask the stack which way the flow is going? That would be valid. Does it try to dictate which way the flow will go? Also valid. Does it attempt to establish a flow over each interface? Also valid. Does it have a UI to allow the user to exclude some interfaces from measurement? Etc. > The answer likely is 'it depends on what kind of interfaces the OS provides to an MA and the nature of a specific test and the context in which a measurement task is executed'. I know, for example, people measuring how IPv6 access to web services differs from IPv4 access to services. In this case, a test utilizing both IPv4 and IPv6 is a rather natural thing. I see questions here where I think we need to separate the mechanisms from the policies that can be built with them and concentrate on the development of mechanisms that allow to implement useful policies. We should stay away from 'hard coding' certain policies into a solution (if that is possible at all). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Ted.Lemon@nominum.com Mon May 13 14:05:00 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E72321F87C5 for ; Mon, 13 May 2013 14:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fYpcc+DXE3G for ; Mon, 13 May 2013 14:04:53 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 714A021F8A00 for ; Mon, 13 May 2013 14:04:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUZFVdeX/ct1xfKNY9TDU/TdlOTsYNcJU@postini.com; Mon, 13 May 2013 14:04:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EBA4C1B8162 for ; Mon, 13 May 2013 14:04:52 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E30DF19005D; Mon, 13 May 2013 14:04:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 13 May 2013 14:04:52 -0700 From: Ted Lemon To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP: situation: Question 4: Measurement Agent device type Thread-Index: AQHOT/Xdy0KURQg4wU6Hlns4VHBwHJkD2rSAgAAUeYCAAB4AAIAAA0SA Date: Mon, 13 May 2013 21:04:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775180C11@mbx-01.win.nominum.com> References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> <20130507050348.GA56873@elstar.local> <519112C0.2080809@cisco.com> <20130513175230.GB10091@elstar.local> <8D23D4052ABE7A4490E77B1A012B6307751807ED@mbx-01.win.nominum.com> <20130513205308.GA10839@elstar.local> In-Reply-To: <20130513205308.GA10839@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <04EF2AF90012AA4AAA6E8F44364662B8@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 21:05:00 -0000 On May 13, 2013, at 4:53 PM, Juergen Schoenwaelder wrote: > I see questions here where I think we need to separate the mechanisms > from the policies that can be built with them and concentrate on the > development of mechanisms that allow to implement useful policies. We > should stay away from 'hard coding' certain policies into a solution > (if that is possible at all). Yup. The reason I suggest considering the questions I asked is not so tha= t you can come up with specific policies, but so that you can give implemen= tors advice about what to do in these situations. The MIF working group i= s working on an architecture document that'll talk about these problems in = a more general way, but your application is a good example of one where the= se issues can definitely be expected to come up. I don't have a strong op= inion about what you should do to address this, but Benoit thought you prob= ably ought to do something, and that makes sense to me too. From bs7652@att.com Mon May 13 14:25:45 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131CB21F93EA for ; Mon, 13 May 2013 14:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-p5ZhrmavfD for ; Mon, 13 May 2013 14:25:38 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id E3F7421F93B1 for ; Mon, 13 May 2013 14:25:37 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 15a51915.783f7940.175187.00-570.473121.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 13 May 2013 21:25:37 +0000 (UTC) X-MXL-Hash: 51915a511ea832a8-f594b410528a975f50d9cf679dfdad30d5899ff3 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 15a51915.0.175180.00-442.473098.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 13 May 2013 21:25:37 +0000 (UTC) X-MXL-Hash: 51915a510e5c2ba0-741cd1cdf9811cfcba619201a75fc9c58527d47f Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4DLPZio014990; Mon, 13 May 2013 17:25:37 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4DLPNbh014655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 May 2013 17:25:30 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by alpi132.aldc.att.com (RSA Interceptor); Mon, 13 May 2013 21:25:09 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0342.003; Mon, 13 May 2013 17:25:09 -0400 From: "STARK, BARBARA H" To: Benoit Claise , "lmap@ietf.org" Thread-Topic: [lmap] LMAP: situation: Question 4: Measurement Agent device type Thread-Index: AQHOT/XiZuR8sJ4UQE+r/nXqxVKeD5kDln9g Date: Mon, 13 May 2013 21:25:08 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302B0FD9@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <5187C97C.7080409@cisco.com> <20130506153423.GC54841@elstar.local> <5188294A.9050409@cisco.com> <20130507050348.GA56873@elstar.local> <519112C0.2080809@cisco.com> In-Reply-To: <519112C0.2080809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.59.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Mc3bTeDf c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=BGtaYnrquNMA:10 a=v0c_YqzsWCcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=HBCFWvtQQc0A:10 a=Qs0Qe9JHPvnEL3ouqSoA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Subject: Re: [lmap] LMAP: situation: Question 4: Measurement Agent device type X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 21:25:45 -0000 > However, if I chose to, then yes, I want to be able to install MA on any = of my > devices. > In that case, we have some more questions: > - what about service parameters, which my devices don't know about? > Don't care, manual introduction in the MA, or automatic discovery? > - what about multiple interface (IPv4, IPv6, 3G). This is the MIF WG issu= e > - these should be the same tests as my ISP, so that I could compare. How? > Regarding measurement coordinations on my devices, I agree that this migh= t > unavoidable I think I'll try one more time to make a case for being able to supply "ins= ide the home network" devices with service attributes and other info. Here's what I'm thinking: We define a DNS-SD service (RFC 6763) that allows devices to discover the u= rl for an xml page on a router. This xml page can provide service attribute= s (but it doesn't have to; or it can provide some and not others -- whateve= r it's designed or able to provide), WAN link utilization statistics, LAN l= ink metrics, etc. This doesn't have to be limited to ISP routers; "retail" = routers can also have this "service", even though they may not be able to p= rovide service attributes. They could still provide WAN link utilization an= d LAN link statistics and such. What would need to be defined:=20 (1) The RFC 6763 Service Instance Name (Service Instance Name =3D . . ). (2) xml representation of possible data elements. The service parameter xml= will be identical to that which we've already discussed defining for other= uses. We would also need to define xml representation of WAN link utilizat= ion and LAN link metrics.=20 Since privacy rules vary from country to country (some may think it's fine = to provide some or all of this data internal to a home network, others may = want it secured), it would be possible for the url to be defined so that it= can be secure (e.g., https) or not secure (e.g., http). There's probably a= fair amount to be said about privacy, but I think it can be said, by provi= ding options and without attempting to legislate privacy in IETF. Last time I suggested this, there were a number of people who expressed opp= osition, because they saw no reason to ever provide service attributes to a= non-ISP MA inside the home network. But maybe I didn't explain it right. J= ust because this capability is defined, doesn't mean anyone has to implemen= t it in their router. If an ISP doesn't want to implement this, then they d= on't implement it. This in no way is intended to prevent or be a substitute= for ISP's managing service attributes in other ways, and it's not intended= to be forced on anyone. But for those who do think defining such a functio= n might be useful, I think it would be pretty easy to define and implement.= And it's not just for "3rd party" MAs, but also for end user MAs that only= the end user controls. Like when an end user wants to try to replicate an = ISP's measurements. I'd be willing to take a stab at writing a draft, if there were interest. Barbara From sharam.hakimi@exfo.com Mon May 13 13:50:23 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBEA21F93F0 for ; Mon, 13 May 2013 13:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-anzaf1mygP for ; Mon, 13 May 2013 13:50:18 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id B716D21F93EE for ; Mon, 13 May 2013 13:50:17 -0700 (PDT) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 16:50:16 -0400 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 16:50:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 May 2013 16:49:31 -0400 Message-ID: <084CDC75FEC1E640B60338273BEACDFA024FA143@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac5P+H2h/hE/rGHTR9qJLebNGkMSYAAGitFgAAGJ+3A= References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net><9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net><51867E8B.5060502@cisco.com><9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net><519116F3.1010503@cisco.com> From: "Sharam Hakimi" To: "MORTON JR., ALFRED C \(AL\)" , "Benoit Claise" , X-OriginalArrivalTime: 13 May 2013 20:50:16.0326 (UTC) FILETIME=[78E9F260:01CE501B] X-Mailman-Approved-At: Mon, 13 May 2013 18:09:51 -0700 Cc: lmap@ietf.org, trevor.burbridge@bt.com, j.schoenwaelder@jacobs-university.de, Michael.K.Bugenhagen@centurylink.com, jason.weil@twcable.com, shane@castlepoint.net, "STARK, BARBARA H" Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 20:50:33 -0000 Benoit, I don't think that the regulator can force you to install any MA on your PC. You might want to if you are unhappy with the results that the ISP provides, as you might not agree with their results. Then installing a MA that is not under an ISP control might help in resolving the issue. One problem with testing from the MA in an ISP router is that the customer interface(connected to the customer network) and capabilities of the ISP router will not be tested. This is because tests are generated within the ISP router with the MA and then sent on the outbound interface to the ISP. Therefore if there are any issues from the customer network side of the ISP router it will not be seen. Having an MA on the PC that you mentioned will test the entire path including the customer interface of the ISP router. It is possible to have other MA agents under ISP control in devices at the same connection point as the PC mentioned below that would be able to test the entire path. Regards, Sharam =20 -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON JR., ALFRED C (AL) Sent: Monday, May 13, 2013 4:17 PM To: Benoit Claise; philip.eardley@bt.com Cc: lmap@ietf.org; trevor.burbridge@bt.com; j.schoenwaelder@jacobs-university.de; Michael.K.Bugenhagen@centurylink.com; jason.weil@twcable.com; shane@castlepoint.net; STARK,BARBARA H Subject: Re: [lmap] LMAP: situation: Q1-Use Cases Hi Benoit, I appreciate that one organization's implementation of LMAP may constrain another's, especially if they both intend to measure almost exactly the same portion of the network. An alternative when the ISP is using an MA on their own gateway/router is that the regulator asks users to volunteer to make measurements, and that's been done many times already with a "white-box". It seems this could be extended to an embedded client with reasonable=20 qualifications, especially connectivity, listening for competing user traffic=20 (that's simple in your single case with a single PC) and perhaps others. An environment with some overlapping measurement coverage seems very likely (to several people on the list). > - Or, because the router is taken, and I don't want to install anything > else in my network, the regulator should get the test reports from the > ISP? I suspect that the agreed measurements and desired results, collected at large scale,=20 and reported in the way a regulator wants, would go a long way to support information gathering without the complexity of maintaining a measurement system.=20 Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Benoit Claise > Sent: Monday, May 13, 2013 12:38 PM > To: philip.eardley@bt.com > Cc: lmap@ietf.org; trevor.burbridge@bt.com; j.schoenwaelder@jacobs- > university.de; Michael.K.Bugenhagen@centurylink.com; > jason.weil@twcable.com; shane@castlepoint.net; STARK, BARBARA H > Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >=20 > On 7/05/2013 16:41, philip.eardley@bt.com wrote: > >>> So in terms of Benoit's questions: > >>> - The Internet Service Provider use case is in scope, assuming that > >>> the ISP controls the functions for the Measurement Agent, Controller > >>> and Collector > >>> - The regulator use case is in scope, assuming that the regulator > >>> controls the functions for the Measurement Agent, Controller and > >>> Collector > >> I'm wondering whether the previous two points are not incompatible? > >> Most ISPs have, or will have, a type of LMAP architecture anyway. When > >> I call my provider (home network), they can already do the type of LMAP > >> tests on my router. So what use case is left of the regulator (knowing > >> the assumption that a MA is under the administration of a single > >> entity)? > >> > > Not sure I get your point - anyway, I don't think they're incompatible. > Let me more explicit. > Example: A home, with a single router and a single PC. > ISP use case: the MA is on the router, under ISP supervision. >=20 > Then what's left for the regulator use case? > - The ideal regulator situation is to get a MA on the router. But the > router is under the ISP supervision in this case. That breaks the > assumption that a MA is under a single supervision. > - So it has to be on my personal device? Do you envision the regulator > forcing me to install something on my personal device because the router > is under the ISP supervision? > - Or do you envision the regulator forcing me to install an extra > probe/MA box in my network? > - Or, because the router is taken, and I don't want to install anything > else in my network, the regulator should get the test reports from the > ISP? >=20 > Regards, Benoit >=20 > > > > The MAs, controller and collector(s) are all under common control > (single measurement system). > > >From a commercial point of view this looks the same as existing systems > - either samknows style measurement systems operated on behalf of a > regulator - or (as you say) where an ISP has measurement functions in a > router. > > Lmap would enable this sort of system to scale better, allow multi- > vendor operation, etc > > > > Thanks > > phil > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > > > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From j.schoenwaelder@jacobs-university.de Tue May 14 01:41:49 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E4721F901B for ; Tue, 14 May 2013 01:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxOsbaCvSpYb for ; Tue, 14 May 2013 01:41:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7A89E21F8F83 for ; Tue, 14 May 2013 01:41:44 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8012820C1A; Tue, 14 May 2013 10:41:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bL7jhVuWIwAS; Tue, 14 May 2013 10:41:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3A6020C0B; Tue, 14 May 2013 10:41:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BBBC62638E46; Tue, 14 May 2013 10:41:40 +0200 (CEST) Date: Tue, 14 May 2013 10:41:40 +0200 From: Juergen Schoenwaelder To: "MORTON JR., ALFRED C (AL)" , Dan Romascanu , Benoit Claise Message-ID: <20130514084140.GA12748@elstar.local> Mail-Followup-To: "MORTON JR., ALFRED C (AL)" , Dan Romascanu , Benoit Claise , lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 08:41:50 -0000 Hi, I am wondering where we are with the charter discussions. I have not seen any revised charter proposal since the BOF in Orlando. I assume that some of the questions asked on this list recently are related to activities revising the draft charter. I am wondering when the draft charter will come back to this list for general review and comments. Perhaps some questions are even easier to answer with a concrete draft charter text available. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Tue May 14 03:26:54 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E714821F8FD0 for ; Tue, 14 May 2013 03:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc0M9-4kLQHx for ; Tue, 14 May 2013 03:26:49 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4444E21F8F69 for ; Tue, 14 May 2013 03:26:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4EAQi5f022268; Tue, 14 May 2013 12:26:45 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4EAQOLm011127; Tue, 14 May 2013 12:26:34 +0200 (CEST) Message-ID: <51921150.60807@cisco.com> Date: Tue, 14 May 2013 12:26:24 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "STARK, BARBARA H" References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> <51867E8B.5060502@cisco.com> <9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net> <519116F3.1010503@cisco.com> <2D09D61DDFA73D4C884805CC7865E611302B0F91@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302B0F91@GAALPA1MSGUSR9L.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 10:26:55 -0000 On 13/05/2013 22:47, STARK, BARBARA H wrote: >> Example: A home, with a single router and a single PC. >> ISP use case: the MA is on the router, under ISP supervision. >> >> Then what's left for the regulator use case? >> - The ideal regulator situation is to get a MA on the router. But the router is >> under the ISP supervision in this case. That breaks the assumption that a MA >> is under a single supervision. > I disagree that this breaks that assumption. The regulator negotiates (out of band) with the ISP as to what measurements get run, measurement peers, etc. The ISP manages the router, manages running of the measurements, and collects the data. The ISP then provides the regulator with the agreed-upon data (which will have been associated with network parameters and scrubbed for privacy, as deemed appropriate). > >> - So it has to be on my personal device? Do you envision the regulator >> forcing me to install something on my personal device because the router is >> under the ISP supervision? >> - Or do you envision the regulator forcing me to install an extra probe/MA >> box in my network? > Forcing is a harsh word. I'm only aware of programs involving voluntary participation, to date. If you wish to participate, then to do so, you may find (in the case where the ISP router doesn't support the regulator-desired MA function) that you are required to have the extra box or install something on a personal device. If you don't want to do this, don't volunteer to participate. > >> - Or, because the router is taken, and I don't want to install anything else in >> my network, the regulator should get the test reports from the ISP? > What's wrong with the regulator getting test reports from the ISP? There is nothing wrong. I'm trying to understand the different use cases, and, as a consequence, which problem(s) this group want to solve. Regards, Benoit > It appears to me that this is exactly what some regulators *want* to do. That is, it seems that some regulators would prefer to get the data from the ISP. If that isn't possible (ISP doesn't provide a router, router is unmanaged, router is too old and can't be updated to support the desired measurements, etc.), then there needs to also be the possibility of the 3rd party MA, with control and data collection done by that same 3rd party (which could be the regulator, but more likely is someone the regulator contracted with -- but all parts under one operational domain). And if the router can't do the needed measurements and you don't want to install anything, then you don't participate in the regulatory measurement collection program. > > 3rd party regulator MAs (in separate boxes or personal device apps) are much more about the case where the router can't do the measurements, than they are about the regulator not wanting or not being able to get measurements that an ISP has collected from an ISP router. [Note: Many people don't have a router provided or managed by the ISP. That includes me. Neither of my 2 ISPs offers me a router.] > Barbara > > From bclaise@cisco.com Tue May 14 03:45:00 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D4D21F8E8E for ; Tue, 14 May 2013 03:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.212 X-Spam-Level: X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGqaqImGAiam for ; Tue, 14 May 2013 03:44:54 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7A76621F86C1 for ; Tue, 14 May 2013 03:44:54 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4EAiocP024469; Tue, 14 May 2013 12:44:51 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4EAiKvn026061; Tue, 14 May 2013 12:44:30 +0200 (CEST) Message-ID: <51921584.8040505@cisco.com> Date: Tue, 14 May 2013 12:44:20 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "MORTON JR., ALFRED C (AL)" , Dan Romascanu , lmap@ietf.org References: <20130514084140.GA12748@elstar.local> In-Reply-To: <20130514084140.GA12748@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 10:45:00 -0000 Hi Jüergen, Timely question. As far as I'm concerned, the couple of clarifying questions I asked on the mailing list are now addressed. Al, Dan, and I are working on the charter proposal. You can expect some charter proposal very soon. Regards, Benoit > Hi, > > I am wondering where we are with the charter discussions. I have not > seen any revised charter proposal since the BOF in Orlando. I assume > that some of the questions asked on this list recently are related to > activities revising the draft charter. > > I am wondering when the draft charter will come back to this list for > general review and comments. Perhaps some questions are even easier to > answer with a concrete draft charter text available. > > /js > From bclaise@cisco.com Tue May 14 03:30:03 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E831221F854D for ; Tue, 14 May 2013 03:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.32 X-Spam-Level: X-Spam-Status: No, score=-9.32 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSu+D9iVu+Bg for ; Tue, 14 May 2013 03:30:00 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B06BB21F853A for ; Tue, 14 May 2013 03:29:59 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4EATm3C022688; Tue, 14 May 2013 12:29:48 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4EASOno012817; Tue, 14 May 2013 12:28:34 +0200 (CEST) Message-ID: <519211C8.5040209@cisco.com> Date: Tue, 14 May 2013 12:28:24 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: philip.eardley@bt.com References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net><9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net><51867E8B.5060502@cisco.com><9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net><519116F3.1010503@cisco.com> <084CDC75FEC1E640B60338273BEACDFA024FA143@spboexc01.exfo.com> <9510D26531EF184D9017DF24659BB87F3475406F0C@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3475406F0C@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 14 May 2013 08:14:35 -0700 Cc: sharam.hakimi@exfo.com, acmorton@att.com, lmap@ietf.org, trevor.burbridge@bt.com, j.schoenwaelder@jacobs-university.de, Michael.K.Bugenhagen@centurylink.com, jason.weil@twcable.com, shane@castlepoint.net, bs7652@att.com Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 10:30:04 -0000 Philip, > Benoit > Thanks for clarifying. Basically agree with Al and Sharam's points. > > I think there are several ways this could happen. > - regulator has MAs with different subset of customers (as today) > - regulator installs MA in parallel with ISP's (so some customers have MA from both regulator and ISP) > - ISP lends some MAs to the regulator (which get Instructions from the regulator's Controller and report to the regulator's Collector) (The "lending protocol" is out of scope) > - ISP gives regulator some results (per MA or aggregated) (ie from ISP's Collector) > - etc > > Personally I think the LMAP work is unaffected - we simply do the control protocol and report protocol. Thanks for the clarification. Regards, Benoit > > >> -----Original Message----- >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> Sent: 13 May 2013 21:50 >> To: MORTON JR., ALFRED C (AL); Benoit Claise; Eardley,PL,Philip,TUB8 R >> Cc: lmap@ietf.org; Burbridge,T,Trevor,TUB8 R; j.schoenwaelder@jacobs- >> university.de; Michael.K.Bugenhagen@centurylink.com; >> jason.weil@twcable.com; shane@castlepoint.net; STARK,BARBARA H >> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >> >> Benoit, >> >> I don't think that the regulator can force you to install any MA on >> your PC. You might want to if you are unhappy with the results that the >> ISP provides, as you might not agree with their results. Then >> installing a MA that is not under an ISP control might help in >> resolving the issue. >> >> One problem with testing from the MA in an ISP router is that the >> customer interface(connected to the customer network) and capabilities >> of the ISP router will not be tested. This is because tests are >> generated within the ISP router with the MA and then sent on the >> outbound interface to the ISP. Therefore if there are any issues from >> the customer network side of the ISP router it will not be seen. Having >> an MA on the PC that you mentioned will test the entire path including >> the customer interface of the ISP router. >> >> It is possible to have other MA agents under ISP control in devices at >> the same connection point as the PC mentioned below that would be able >> to test the entire path. >> >> Regards, >> Sharam >> >> >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >> MORTON JR., ALFRED C (AL) >> Sent: Monday, May 13, 2013 4:17 PM >> To: Benoit Claise; philip.eardley@bt.com >> Cc: lmap@ietf.org; trevor.burbridge@bt.com; j.schoenwaelder@jacobs- >> university.de; >> Michael.K.Bugenhagen@centurylink.com; jason.weil@twcable.com; >> shane@castlepoint.net; STARK,BARBARA H >> Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >> >> Hi Benoit, >> >> I appreciate that one organization's implementation of LMAP may >> constrain another's, especially if they both intend to measure almost >> exactly the same portion of the network. An alternative when the ISP is >> using an MA on their own gateway/router is that the regulator asks >> users to volunteer to make measurements, and that's been done many >> times already with a "white-box". It seems this could be extended to an >> embedded client with reasonable qualifications, especially >> connectivity, listening for competing user traffic (that's simple in >> your single case with a single PC) and perhaps others. An environment >> with some overlapping measurement coverage seems very likely (to >> several people on the list). >> >>> - Or, because the router is taken, and I don't want to install >> anything >>> else in my network, the regulator should get the test reports from >> the >>> ISP? >> I suspect that the agreed measurements and desired results, collected >> at large scale, and reported in the way a regulator wants, would go a >> long way to support information gathering without the complexity of >> maintaining a measurement system. >> >> Al >> >>> -----Original Message----- >>> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf >> Of >>> Benoit Claise >>> Sent: Monday, May 13, 2013 12:38 PM >>> To: philip.eardley@bt.com >>> Cc: lmap@ietf.org; trevor.burbridge@bt.com; j.schoenwaelder@jacobs- >>> university.de; Michael.K.Bugenhagen@centurylink.com; >>> jason.weil@twcable.com; shane@castlepoint.net; STARK, BARBARA H >>> Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >>> >>> On 7/05/2013 16:41, philip.eardley@bt.com wrote: >>>>>> So in terms of Benoit's questions: >>>>>> - The Internet Service Provider use case is in scope, assuming >> that >>>>>> the ISP controls the functions for the Measurement Agent, >> Controller >>>>>> and Collector >>>>>> - The regulator use case is in scope, assuming that the regulator >>>>>> controls the functions for the Measurement Agent, Controller and >>>>>> Collector >>>>> I'm wondering whether the previous two points are not >> incompatible? >>>>> Most ISPs have, or will have, a type of LMAP architecture anyway. >> When >>>>> I call my provider (home network), they can already do the type of >> LMAP >>>>> tests on my router. So what use case is left of the regulator >> (knowing >>>>> the assumption that a MA is under the administration of a single >>>>> entity)? >>>>> >>>> Not sure I get your point - anyway, I don't think they're >> incompatible. >>> Let me more explicit. >>> Example: A home, with a single router and a single PC. >>> ISP use case: the MA is on the router, under ISP supervision. >>> >>> Then what's left for the regulator use case? >>> - The ideal regulator situation is to get a MA on the router. But the >>> router is under the ISP supervision in this case. That breaks the >>> assumption that a MA is under a single supervision. >>> - So it has to be on my personal device? Do you envision the >> regulator >>> forcing me to install something on my personal device because the >> router >>> is under the ISP supervision? >>> - Or do you envision the regulator forcing me to install an extra >>> probe/MA box in my network? >>> - Or, because the router is taken, and I don't want to install >> anything >>> else in my network, the regulator should get the test reports from >> the >>> ISP? >>> >>> Regards, Benoit >>> >>>> The MAs, controller and collector(s) are all under common control >>> (single measurement system). >>>> >From a commercial point of view this looks the same as existing >> systems >>> - either samknows style measurement systems operated on behalf of a >>> regulator - or (as you say) where an ISP has measurement functions in >> a >>> router. >>>> Lmap would enable this sort of system to scale better, allow multi- >>> vendor operation, etc >>>> Thanks >>>> phil >>>> _______________________________________________ >>>> lmap mailing list >>>> lmap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lmap >>>> >>>> >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > From philip.eardley@bt.com Tue May 14 00:39:14 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6CE21F8FF2 for ; Tue, 14 May 2013 00:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYdYW2F9ppOw for ; Tue, 14 May 2013 00:39:10 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4573D21F8935 for ; Tue, 14 May 2013 00:39:08 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 14 May 2013 08:39:06 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.197]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 14 May 2013 08:39:06 +0100 From: To: , , Date: Tue, 14 May 2013 08:39:05 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac5P+H2h/hE/rGHTR9qJLebNGkMSYAAGitFgAAGJ+3AAFtFeYA== Message-ID: <9510D26531EF184D9017DF24659BB87F3475406F0C@EMV65-UKRD.domain1.systemhost.net> References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net><9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net><51867E8B.5060502@cisco.com><9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net><519116F3.1010503@cisco.com> <084CDC75FEC1E640B60338273BEACDFA024FA143@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA024FA143@spboexc01.exfo.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 14 May 2013 08:14:36 -0700 Cc: lmap@ietf.org, trevor.burbridge@bt.com, j.schoenwaelder@jacobs-university.de, Michael.K.Bugenhagen@centurylink.com, jason.weil@twcable.com, shane@castlepoint.net, bs7652@att.com Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 07:39:14 -0000 Benoit=20 Thanks for clarifying. Basically agree with Al and Sharam's points. I think there are several ways this could happen. - regulator has MAs with different subset of customers (as today) - regulator installs MA in parallel with ISP's (so some customers have MA f= rom both regulator and ISP) - ISP lends some MAs to the regulator (which get Instructions from the regu= lator's Controller and report to the regulator's Collector) (The "lending p= rotocol" is out of scope) - ISP gives regulator some results (per MA or aggregated) (ie from ISP's Co= llector) - etc Personally I think the LMAP work is unaffected - we simply do the control p= rotocol and report protocol.=20 > -----Original Message----- > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: 13 May 2013 21:50 > To: MORTON JR., ALFRED C (AL); Benoit Claise; Eardley,PL,Philip,TUB8 R > Cc: lmap@ietf.org; Burbridge,T,Trevor,TUB8 R; j.schoenwaelder@jacobs- > university.de; Michael.K.Bugenhagen@centurylink.com; > jason.weil@twcable.com; shane@castlepoint.net; STARK,BARBARA H > Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >=20 > Benoit, >=20 > I don't think that the regulator can force you to install any MA on > your PC. You might want to if you are unhappy with the results that the > ISP provides, as you might not agree with their results. Then > installing a MA that is not under an ISP control might help in > resolving the issue. >=20 > One problem with testing from the MA in an ISP router is that the > customer interface(connected to the customer network) and capabilities > of the ISP router will not be tested. This is because tests are > generated within the ISP router with the MA and then sent on the > outbound interface to the ISP. Therefore if there are any issues from > the customer network side of the ISP router it will not be seen. Having > an MA on the PC that you mentioned will test the entire path including > the customer interface of the ISP router. >=20 > It is possible to have other MA agents under ISP control in devices at > the same connection point as the PC mentioned below that would be able > to test the entire path. >=20 > Regards, > Sharam >=20 >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > MORTON JR., ALFRED C (AL) > Sent: Monday, May 13, 2013 4:17 PM > To: Benoit Claise; philip.eardley@bt.com > Cc: lmap@ietf.org; trevor.burbridge@bt.com; j.schoenwaelder@jacobs- > university.de; > Michael.K.Bugenhagen@centurylink.com; jason.weil@twcable.com; > shane@castlepoint.net; STARK,BARBARA H > Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >=20 > Hi Benoit, >=20 > I appreciate that one organization's implementation of LMAP may > constrain another's, especially if they both intend to measure almost > exactly the same portion of the network. An alternative when the ISP is > using an MA on their own gateway/router is that the regulator asks > users to volunteer to make measurements, and that's been done many > times already with a "white-box". It seems this could be extended to an > embedded client with reasonable qualifications, especially > connectivity, listening for competing user traffic (that's simple in > your single case with a single PC) and perhaps others. An environment > with some overlapping measurement coverage seems very likely (to > several people on the list). >=20 > > - Or, because the router is taken, and I don't want to install > anything > > else in my network, the regulator should get the test reports from > the > > ISP? >=20 > I suspect that the agreed measurements and desired results, collected > at large scale, and reported in the way a regulator wants, would go a > long way to support information gathering without the complexity of > maintaining a measurement system. >=20 > Al >=20 > > -----Original Message----- > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > Of > > Benoit Claise > > Sent: Monday, May 13, 2013 12:38 PM > > To: philip.eardley@bt.com > > Cc: lmap@ietf.org; trevor.burbridge@bt.com; j.schoenwaelder@jacobs- > > university.de; Michael.K.Bugenhagen@centurylink.com; > > jason.weil@twcable.com; shane@castlepoint.net; STARK, BARBARA H > > Subject: Re: [lmap] LMAP: situation: Q1-Use Cases > > > > On 7/05/2013 16:41, philip.eardley@bt.com wrote: > > >>> So in terms of Benoit's questions: > > >>> - The Internet Service Provider use case is in scope, assuming > that > > >>> the ISP controls the functions for the Measurement Agent, > Controller > > >>> and Collector > > >>> - The regulator use case is in scope, assuming that the regulator > > >>> controls the functions for the Measurement Agent, Controller and > > >>> Collector > > >> I'm wondering whether the previous two points are not > incompatible? > > >> Most ISPs have, or will have, a type of LMAP architecture anyway. > When > > >> I call my provider (home network), they can already do the type of > LMAP > > >> tests on my router. So what use case is left of the regulator > (knowing > > >> the assumption that a MA is under the administration of a single > > >> entity)? > > >> > > > Not sure I get your point - anyway, I don't think they're > incompatible. > > Let me more explicit. > > Example: A home, with a single router and a single PC. > > ISP use case: the MA is on the router, under ISP supervision. > > > > Then what's left for the regulator use case? > > - The ideal regulator situation is to get a MA on the router. But the > > router is under the ISP supervision in this case. That breaks the > > assumption that a MA is under a single supervision. > > - So it has to be on my personal device? Do you envision the > regulator > > forcing me to install something on my personal device because the > router > > is under the ISP supervision? > > - Or do you envision the regulator forcing me to install an extra > > probe/MA box in my network? > > - Or, because the router is taken, and I don't want to install > anything > > else in my network, the regulator should get the test reports from > the > > ISP? > > > > Regards, Benoit > > > > > > > > The MAs, controller and collector(s) are all under common control > > (single measurement system). > > > >From a commercial point of view this looks the same as existing > systems > > - either samknows style measurement systems operated on behalf of a > > regulator - or (as you say) where an ISP has measurement functions in > a > > router. > > > Lmap would enable this sort of system to scale better, allow multi- > > vendor operation, etc > > > > > > Thanks > > > phil > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From Michael.K.Bugenhagen@centurylink.com Tue May 14 06:21:37 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B0E21F8F53 for ; Tue, 14 May 2013 06:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIdS+2NYx5qc for ; Tue, 14 May 2013 06:21:31 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8A721F8F03 for ; Tue, 14 May 2013 06:21:31 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r4EDLNd0018882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 May 2013 07:21:23 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 4F5EE1E005D; Tue, 14 May 2013 08:21:18 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 2B4561E0058; Tue, 14 May 2013 08:21:18 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r4EDLHdw017391; Tue, 14 May 2013 08:21:17 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r4EDLHWP017385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 May 2013 08:21:17 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.02.0318.001; Tue, 14 May 2013 08:21:17 -0500 From: "Bugenhagen, Michael K" To: "'Benoit Claise'" , "philip.eardley@bt.com" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHQAGitFgAAGJ+3CZBItQgIAAL04A///VC1A= Date: Tue, 14 May 2013 13:21:16 +0000 Message-ID: References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net><9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net><51867E8B.5060502@cisco.com><9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net><519116F3.1010503@cisco.com> <084CDC75FEC1E640B60338273BEACDFA024FA143@spboexc01.exfo.com> <9510D26531EF184D9017DF24659BB87F3475406F0C@EMV65-UKRD.domain1.systemhost.net> <519211C8.5040209@cisco.com> In-Reply-To: <519211C8.5040209@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 14 May 2013 08:14:38 -0700 Cc: "sharam.hakimi@exfo.com" , "acmorton@att.com" , "lmap@ietf.org" , "trevor.burbridge@bt.com" , "j.schoenwaelder@jacobs-university.de" , "jason.weil@twcable.com" , "shane@castlepoint.net" , "bs7652@att.com" Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 13:21:37 -0000 A few points - 1) A single measurement controller sounds great however when considering mu= ltiple technology domains (wireless vs. wireline) and separate operational = domains such as regional network management op's domains - it's simply not = practical. Also the fact that a controller may also be used for traffic stu= dy which is much more intensive than a simple performance study makes regio= nal domain controllers much more flexible, and desirable. - therefore I suggest we not constrict to any "single controller"=20 =20 2) Probe ownership isn't the problem - The Complexity of sold speed is - it= requires validation, which requires a protocol... Having done some analysis on the results data from the Measuring Broadband= America myself and others have found that it's critical to know the "promi= sed speed" vs. assuming you know the speed. Terms of service have changed= over time to include use cap's that can change your expected speed, and if= we're truly international in observing service definition, the expected sp= eeds can change with the time of day. To this point, if the results are going to have solid scientific methods= they almost certainly require a time of day expected or promised speed num= ber for the ISP. =20 - I recommend part of the scope to include a protocol to obtain that ex= pected speed from the ISP. Placing the correct information in the hands of the customer, ISP and reg= ulators is good - so the data needs to be as solid as possible. Personally I don't recommend "splicing" the information after the fact, I= think a test protocol that retrieves expected speed at the time of the t= est is the way to go. =09 Thanks, Mike =20 -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Tuesday, May 14, 2013 5:28 AM To: philip.eardley@bt.com Cc: sharam.hakimi@exfo.com; acmorton@att.com; lmap@ietf.org; trevor.burbrid= ge@bt.com; j.schoenwaelder@jacobs-university.de; Bugenhagen, Michael K; jas= on.weil@twcable.com; shane@castlepoint.net; bs7652@att.com Subject: Re: [lmap] LMAP: situation: Q1-Use Cases Philip, > Benoit > Thanks for clarifying. Basically agree with Al and Sharam's points. > > I think there are several ways this could happen. > - regulator has MAs with different subset of customers (as today) > - regulator installs MA in parallel with ISP's (so some customers have=20 > MA from both regulator and ISP) > - ISP lends some MAs to the regulator (which get Instructions from the=20 > regulator's Controller and report to the regulator's Collector) (The=20 > "lending protocol" is out of scope) > - ISP gives regulator some results (per MA or aggregated) (ie from=20 > ISP's Collector) > - etc > > Personally I think the LMAP work is unaffected - we simply do the control= protocol and report protocol. Thanks for the clarification. Regards, Benoit > > >> -----Original Message----- >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> Sent: 13 May 2013 21:50 >> To: MORTON JR., ALFRED C (AL); Benoit Claise; Eardley,PL,Philip,TUB8=20 >> R >> Cc: lmap@ietf.org; Burbridge,T,Trevor,TUB8 R; j.schoenwaelder@jacobs-=20 >> university.de; Michael.K.Bugenhagen@centurylink.com; >> jason.weil@twcable.com; shane@castlepoint.net; STARK,BARBARA H >> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >> >> Benoit, >> >> I don't think that the regulator can force you to install any MA on=20 >> your PC. You might want to if you are unhappy with the results that=20 >> the ISP provides, as you might not agree with their results. Then=20 >> installing a MA that is not under an ISP control might help in=20 >> resolving the issue. >> >> One problem with testing from the MA in an ISP router is that the=20 >> customer interface(connected to the customer network) and=20 >> capabilities of the ISP router will not be tested. This is because=20 >> tests are generated within the ISP router with the MA and then sent=20 >> on the outbound interface to the ISP. Therefore if there are any=20 >> issues from the customer network side of the ISP router it will not=20 >> be seen. Having an MA on the PC that you mentioned will test the=20 >> entire path including the customer interface of the ISP router. >> >> It is possible to have other MA agents under ISP control in devices=20 >> at the same connection point as the PC mentioned below that would be=20 >> able to test the entire path. >> >> Regards, >> Sharam >> >> >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf=20 >> Of MORTON JR., ALFRED C (AL) >> Sent: Monday, May 13, 2013 4:17 PM >> To: Benoit Claise; philip.eardley@bt.com >> Cc: lmap@ietf.org; trevor.burbridge@bt.com; j.schoenwaelder@jacobs-=20 >> university.de; Michael.K.Bugenhagen@centurylink.com;=20 >> jason.weil@twcable.com; shane@castlepoint.net; STARK,BARBARA H >> Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >> >> Hi Benoit, >> >> I appreciate that one organization's implementation of LMAP may=20 >> constrain another's, especially if they both intend to measure almost=20 >> exactly the same portion of the network. An alternative when the ISP=20 >> is using an MA on their own gateway/router is that the regulator asks=20 >> users to volunteer to make measurements, and that's been done many=20 >> times already with a "white-box". It seems this could be extended to=20 >> an embedded client with reasonable qualifications, especially=20 >> connectivity, listening for competing user traffic (that's simple in=20 >> your single case with a single PC) and perhaps others. An environment=20 >> with some overlapping measurement coverage seems very likely (to=20 >> several people on the list). >> >>> - Or, because the router is taken, and I don't want to install >> anything >>> else in my network, the regulator should get the test reports from >> the >>> ISP? >> I suspect that the agreed measurements and desired results, collected=20 >> at large scale, and reported in the way a regulator wants, would go a=20 >> long way to support information gathering without the complexity of=20 >> maintaining a measurement system. >> >> Al >> >>> -----Original Message----- >>> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf >> Of >>> Benoit Claise >>> Sent: Monday, May 13, 2013 12:38 PM >>> To: philip.eardley@bt.com >>> Cc: lmap@ietf.org; trevor.burbridge@bt.com; j.schoenwaelder@jacobs-=20 >>> university.de; Michael.K.Bugenhagen@centurylink.com; >>> jason.weil@twcable.com; shane@castlepoint.net; STARK, BARBARA H >>> Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >>> >>> On 7/05/2013 16:41, philip.eardley@bt.com wrote: >>>>>> So in terms of Benoit's questions: >>>>>> - The Internet Service Provider use case is in scope, assuming >> that >>>>>> the ISP controls the functions for the Measurement Agent, >> Controller >>>>>> and Collector >>>>>> - The regulator use case is in scope, assuming that the regulator=20 >>>>>> controls the functions for the Measurement Agent, Controller and=20 >>>>>> Collector >>>>> I'm wondering whether the previous two points are not >> incompatible? >>>>> Most ISPs have, or will have, a type of LMAP architecture anyway. >> When >>>>> I call my provider (home network), they can already do the type of >> LMAP >>>>> tests on my router. So what use case is left of the regulator >> (knowing >>>>> the assumption that a MA is under the administration of a single=20 >>>>> entity)? >>>>> >>>> Not sure I get your point - anyway, I don't think they're >> incompatible. >>> Let me more explicit. >>> Example: A home, with a single router and a single PC. >>> ISP use case: the MA is on the router, under ISP supervision. >>> >>> Then what's left for the regulator use case? >>> - The ideal regulator situation is to get a MA on the router. But=20 >>> the router is under the ISP supervision in this case. That breaks=20 >>> the assumption that a MA is under a single supervision. >>> - So it has to be on my personal device? Do you envision the >> regulator >>> forcing me to install something on my personal device because the >> router >>> is under the ISP supervision? >>> - Or do you envision the regulator forcing me to install an extra=20 >>> probe/MA box in my network? >>> - Or, because the router is taken, and I don't want to install >> anything >>> else in my network, the regulator should get the test reports from >> the >>> ISP? >>> >>> Regards, Benoit >>> >>>> The MAs, controller and collector(s) are all under common control >>> (single measurement system). >>>> >From a commercial point of view this looks the same as existing >> systems >>> - either samknows style measurement systems operated on behalf of a=20 >>> regulator - or (as you say) where an ISP has measurement functions=20 >>> in >> a >>> router. >>>> Lmap would enable this sort of system to scale better, allow multi- >>> vendor operation, etc >>>> Thanks >>>> phil >>>> _______________________________________________ >>>> lmap mailing list >>>> lmap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lmap >>>> >>>> >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > From trevor.burbridge@bt.com Tue May 14 07:27:18 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BD921F86D8 for ; Tue, 14 May 2013 07:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9kyD4PFCnaG for ; Tue, 14 May 2013 07:27:11 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id AB4FB21F87C5 for ; Tue, 14 May 2013 07:27:04 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 14 May 2013 15:27:03 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.17]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Tue, 14 May 2013 15:27:01 +0100 From: To: , , Date: Tue, 14 May 2013 15:27:00 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHQAGitFgAAGJ+3CZBItQgIAAL04A///VC1CAABX2sA== Message-ID: References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net><9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net><51867E8B.5060502@cisco.com><9510D26531EF184D9017DF24659BB87F346DC9A739@EMV65-UKRD.domain1.systemhost.net><519116F3.1010503@cisco.com> <084CDC75FEC1E640B60338273BEACDFA024FA143@spboexc01.exfo.com> <9510D26531EF184D9017DF24659BB87F3475406F0C@EMV65-UKRD.domain1.systemhost.net> <519211C8.5040209@cisco.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 14 May 2013 08:14:37 -0700 Cc: sharam.hakimi@exfo.com, acmorton@att.com, lmap@ietf.org, j.schoenwaelder@jacobs-university.de, jason.weil@twcable.com, shane@castlepoint.net, bs7652@att.com Subject: Re: [lmap] LMAP: situation: Q1-Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 14:27:18 -0000 >-----Original Message----- >From: Bugenhagen, Michael K >[mailto:Michael.K.Bugenhagen@centurylink.com] >Sent: 14 May 2013 14:21 >To: 'Benoit Claise'; Eardley,PL,Philip,TUB8 R >Cc: sharam.hakimi@exfo.com; acmorton@att.com; lmap@ietf.org; >Burbridge,T,Trevor,TUB8 R; j.schoenwaelder@jacobs-university.de; >jason.weil@twcable.com; shane@castlepoint.net; bs7652@att.com >Subject: RE: [lmap] LMAP: situation: Q1-Use Cases > >A few points - > >1) A single measurement controller sounds great however when considering >multiple technology domains (wireless vs. wireline) and separate operation= al >domains such as regional network management op's domains - it's simply >not practical. Also the fact that a controller may also be used for traffi= c study >which is much more intensive than a simple performance study makes >regional domain controllers much more flexible, and desirable. > - therefore I suggest we not constrict to any "single controller" We were suggesting a single controller at any point in time for a single MA= to avoid any negotiation between MA and controllers over resources. Of cou= rse you can have multiple disjoint sets of MAs under multiple controllers w= ith this restriction. I'm not sure but I hope you're not suggesting franchised geographic control= lers. You can't force someone to control their tests through another party. >2) Probe ownership isn't the problem - The Complexity of sold speed is - i= t >requires validation, which requires a protocol... > Having done some analysis on the results data from the Measuring >Broadband America myself and others have found that it's critical to know >the "promised speed" vs. assuming you know the speed. Terms of service >have changed over time to include use cap's that can change your expected >speed, and if we're truly international in observing service definition, t= he >expected speeds can change with the time of day. > To this point, if the results are going to have solid scientific method= s they >almost certainly require a time of day expected or promised speed number >for the ISP. > > - I recommend part of the scope to include a protocol to obtain that >expected speed from the ISP. > Placing the correct information in the hands of the customer, ISP >and regulators is good - so the data needs to be as solid as possible. > > Personally I don't recommend "splicing" the information >after the fact, I think a test protocol that retrieves expected speed at t= he >time of the test is the way to go. Splicing extra information into the measurement data "after the fact" _will= _ occur. There is a mass of operational data that I use to analyse the perf= ormance of my lines that cannot possibly be shared with the MA (because the= re's too much of it, I don't know what it is at the time, it's not availabl= e at the time of testing or I don't trust the MA with it). The question more appropriately is should a subset of this information be s= hared with the MA to report back along with the measurement data? If this i= s for the end-user I also don't know that the measurement results and/or th= e line characteristics couldn't be shared via a web portal. Is there really= a need to give this to the MA in a standard way? Trevor. From philip.eardley@bt.com Wed May 15 01:11:04 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B3B21F8ED8 for ; Wed, 15 May 2013 01:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBvo4-Yx5U7B for ; Wed, 15 May 2013 01:10:59 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2F72C21F85CE for ; Wed, 15 May 2013 01:10:54 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 15 May 2013 09:10:42 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.197]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 15 May 2013 09:10:20 +0100 From: To: Date: Wed, 15 May 2013 09:10:19 +0100 Thread-Topic: Missing concept from draft-eardley-lmap-terminology-01.txt Thread-Index: Ac5Pa0ngWDZbSR4NTl66Yuuqv00ovgB1pwdg Message-ID: <9510D26531EF184D9017DF24659BB87F347540758F@EMV65-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F347540758FEMV65UKRDdoma_" MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] Missing concept from draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 08:11:04 -0000 --_000_9510D26531EF184D9017DF24659BB87F347540758FEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable << I would like to have precise but technology independent terms for the bo= undary between shared and unshared access resources>> This seems a nice idea to me As you say, different technologies have the shared/unshared boundary at dif= ferent distances from the customer. This means that great care is needed if= comparing results to the "sharing point" in two different networks I also agree that having a virtualised example would be good. Ps think you're referring to http://tools.ietf.org/html/draft-morton-ippm-l= map-path-01 ? - though an open question whether any of the terms from there= should be migrated into http://tools.ietf.org/html/draft-eardley-lmap-term= inology-01 - might be nice to have them all in one place? Although organisa= tionally one draft sits in ippm and the other in lmap Thanks! phil From: Matt Mathis [mailto:mattmathis@google.com] Sent: 13 May 2013 00:49 To: Eardley,PL,Philip,TUB8 R Cc: lmap@ietf.org Subject: Missing concept from draft-eardley-lmap-terminology-01.txt Most of the terminology in this draft defined by routing and addressing con= cepts. For measurement, it is also important to have terminology to descr= ibe traffic aggregation. Especially important is over which subpaths might= one customer's traffic be subject to resource contention with other custom= ers? I would like to have precise but technology independent terms for the bound= ary between shared and unshared access resources. Note that for many tech= nologies (mobile service, DOCSIS) this is very close to the service demarc = at the customer. For others, such as FTTH and DSL it typically occurs in c= entralized location. The measurement problems on either side of this boundary are extremely diff= erent, and we need to be able to unambiguously make this dichotomy. I use "unshared access", "shared access", and "sharing point." Note that = for many technologies the sharing point is L2 or lower, so there might not = a natural way to connect a MP at the sharing point. There is also the risk that addressing and routing are going to become prog= ressively less relevant as more and more of the network becomes virtualized= through such technologies as software defined networks. I consider owne= rship (responsibility), traffic aggregation and resource contention to be f= ar more important than addressing. Also, "Destination host" is a rather odd choice for a content provider. P= erhaps "core service provider." Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our serv= ices to speak in defiance of unjust governments. We treat privacy and sec= urity as matters of life and death, because for some users, they are. On Thu, May 2, 2013 at 2:52 AM, > wrote: I updated the draft http://tools.ietf.org/html/draft-eardley-lmap-terminolo= gy Thank-you for all the comments! (the draft is a possible starting point for terminology for the prospective= lmap wg) Best wishes phil -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: 02 May 2013 09:40 To: Al Morton; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; Al C.Mo= rton; Marcelo Bagnulo Subject: New Version Notification for draft-eardley-lmap-terminology-01.txt A new version of I-D, draft-eardley-lmap-terminology-01.txt has been successfully submitted by Philip Eardley and posted to the IETF re= pository. Filename: draft-eardley-lmap-terminology Revision: 01 Title: Terminology for Large MeAsurement Platforms (LMAP) Creation date: 2013-05-02 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-eardley-lmap-ter= minology-01.txt Status: http://datatracker.ietf.org/doc/draft-eardley-lmap-termino= logy Htmlized: http://tools.ietf.org/html/draft-eardley-lmap-terminology-= 01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-eardley-lmap-term= inology-01 Abstract: This documents defines terminology for Large Scale Measurement Platforms. The IETF Secretariat _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_9510D26531EF184D9017DF24659BB87F347540758FEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<< I would like to= have precise but technology independent terms for the boundary between sha= red and unshared access resources>>

This seems a nice idea to me

&nbs= p;

As you say, different technologies have th= e shared/unshared boundary at different distances from the customer. This m= eans that great care is needed if comparing results to the “sharing p= oint” in two different networks

 

I also agree that having a virtuali= sed example would be good.

 

Ps think you’re referring to http://tools.iet= f.org/html/draft-morton-ippm-lmap-path-01 ? - though an open question w= hether any of the terms from there should be migrated into http://tools.ietf.= org/html/draft-eardley-lmap-terminology-01 – might be nice to hav= e them all in one place? Although organisationally one draft sits in ippm a= nd the other in lmap

 <= /p>

Thanks!
phil

 

From: Matt Mathis [mailto:mattmathis@google.com]
Sent: 13 May 2013 = 00:49
To: Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.orgSubject: Missing concept from draft-eardley-lmap-terminology-01.txt=

 

Most of the terminology in this draft defined by= routing and addressing concepts.   For measurement, it is also import= ant to have terminology to describe traffic aggregation.  Especially i= mportant is over which subpaths might one customer's traffic be subject to = resource contention with other customers?

 

I would like to= have precise but technology independent terms for the boundary between sha= red and unshared access resources.   Note that for many technologies (= mobile service, DOCSIS) this is very close to the service demarc at the cus= tomer.  For others, such as FTTH and DSL it typically occurs in centra= lized location.

 

The measurement problems on either = side of this boundary are extremely different, and we need to be able to un= ambiguously make this dichotomy.

 

I use "unshar= ed access", "shared access", and "sharing point." =   Note that for many technologies the sharing point is L2 or lower, so= there might not a natural way to connect a MP at the sharing point.

 

There is also the risk that addressing and routing are go= ing to become progressively less relevant as more and more of the network b= ecomes virtualized through such technologies as software defined networks. =    I consider ownership (responsibility), traffic aggregation and= resource contention to be far more important than addressing.

 

Also, "Destination host" is a rather odd choice for = a content provider.   Perhaps "core service provider."<= /o:p>


Thanks,

--MM--
The best way to predict the future is to create it. =  - Alan Kay

Privacy matters!  We know from recent events t= hat people are using our services to speak in defiance of unjust government= s.   We treat privacy and security as matters of life and death, becau= se for some users, they are.

 

On Thu, May 2, 2013 at 2:52 AM, <philip.eardley@bt.com> wrote:

=

I updated the draft http://tools= .ietf.org/html/draft-eardley-lmap-terminology
Thank-you for all the = comments!

(the draft is a possible starting point for terminology fo= r the prospective lmap wg)

Best wishes
phil

-----Original = Message-----
From: internet-= drafts@ietf.org [mailto:int= ernet-drafts@ietf.org]
Sent: 02 May 2013 09:40
To: Al Morton; Ear= dley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; Al C.Morton; Marcelo Bagn= ulo
Subject: New Version Notification for draft-eardley-lmap-terminology= -01.txt


A new version of I-D, draft-eardley-lmap-terminology-01.= txt
has been successfully submitted by Philip Eardley and posted to the = IETF repository.

Filename:        draft-eardley-= lmap-terminology
Revision:        01
Title:  = ;         Terminology for Large MeAsurement Platforms (= LMAP)
Creation date:   2013-05-02
Group:       &n= bsp;   Individual Submission
Number of pages: 10
URL:   &nb= sp;         http://www.iet= f.org/internet-drafts/draft-eardley-lmap-terminology-01.txt
Status: =          http://datatracker.ietf= .org/doc/draft-eardley-lmap-terminology
Htmlized:     &nbs= p;  http://tools.ietf.org/html/draft-eardley-lmap-term= inology-01
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-eardley-lmap-termino= logy-01

Abstract:
   This documents defines termino= logy for Large Scale Measurement
   Platforms.



=
The IETF Secretariat

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

 

= --_000_9510D26531EF184D9017DF24659BB87F347540758FEMV65UKRDdoma_-- From acmorton@att.com Wed May 15 04:57:42 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752D821F8A53 for ; Wed, 15 May 2013 04:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9BqNx82mNGZ for ; Wed, 15 May 2013 04:57:37 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0674D21F882A for ; Wed, 15 May 2013 04:57:37 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 5D95A1202D7; Wed, 15 May 2013 07:57:35 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id D198DE3C5F; Wed, 15 May 2013 07:57:17 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Wed, 15 May 2013 07:57:36 -0400 From: "MORTON JR., ALFRED C (AL)" To: "philip.eardley@bt.com" , "mattmathis@google.com" Date: Wed, 15 May 2013 07:57:34 -0400 Thread-Topic: [lmap] Missing concept from draft-eardley-lmap-terminology-01.txt Thread-Index: Ac5Pa0ngWDZbSR4NTl66Yuuqv00ovgB1pwdgAAhAjIA= Message-ID: References: <9510D26531EF184D9017DF24659BB87F347540758F@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F347540758F@EMV65-UKRD.domain1.systemhost.net> 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_F1312FAF1A1E624DA0972D1C9A91379A1BFFE38AF8njfpsrvexg7re_" MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] Missing concept from draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 11:57:42 -0000 --_000_F1312FAF1A1E624DA0972D1C9A91379A1BFFE38AF8njfpsrvexg7re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1, Phil and Matt. I intended the reference path to be the basis for discussions like this, especially when seeking equivalent points in different access technologies. Al From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: Wednesday, May 15, 2013 4:10 AM To: mattmathis@google.com Cc: lmap@ietf.org Subject: Re: [lmap] Missing concept from draft-eardley-lmap-terminology-01.= txt << I would like to have precise but technology independent terms for the bo= undary between shared and unshared access resources>> This seems a nice idea to me As you say, different technologies have the shared/unshared boundary at dif= ferent distances from the customer. This means that great care is needed if= comparing results to the "sharing point" in two different networks I also agree that having a virtualised example would be good. Ps think you're referring to http://tools.ietf.org/html/draft-morton-ippm-l= map-path-01 ? - though an open question whether any of the terms from there= should be migrated into http://tools.ietf.org/html/draft-eardley-lmap-term= inology-01 - might be nice to have them all in one place? Although organisa= tionally one draft sits in ippm and the other in lmap Thanks! phil From: Matt Mathis [mailto:mattmathis@google.com] Sent: 13 May 2013 00:49 To: Eardley,PL,Philip,TUB8 R Cc: lmap@ietf.org Subject: Missing concept from draft-eardley-lmap-terminology-01.txt Most of the terminology in this draft defined by routing and addressing con= cepts. For measurement, it is also important to have terminology to descr= ibe traffic aggregation. Especially important is over which subpaths might= one customer's traffic be subject to resource contention with other custom= ers? I would like to have precise but technology independent terms for the bound= ary between shared and unshared access resources. Note that for many tech= nologies (mobile service, DOCSIS) this is very close to the service demarc = at the customer. For others, such as FTTH and DSL it typically occurs in c= entralized location. The measurement problems on either side of this boundary are extremely diff= erent, and we need to be able to unambiguously make this dichotomy. I use "unshared access", "shared access", and "sharing point." Note that = for many technologies the sharing point is L2 or lower, so there might not = a natural way to connect a MP at the sharing point. There is also the risk that addressing and routing are going to become prog= ressively less relevant as more and more of the network becomes virtualized= through such technologies as software defined networks. I consider owne= rship (responsibility), traffic aggregation and resource contention to be f= ar more important than addressing. Also, "Destination host" is a rather odd choice for a content provider. P= erhaps "core service provider." Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our serv= ices to speak in defiance of unjust governments. We treat privacy and sec= urity as matters of life and death, because for some users, they are. On Thu, May 2, 2013 at 2:52 AM, > wrote: I updated the draft http://tools.ietf.org/html/draft-eardley-lmap-terminolo= gy Thank-you for all the comments! (the draft is a possible starting point for terminology for the prospective= lmap wg) Best wishes phil -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: 02 May 2013 09:40 To: Al Morton; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; Al C.Mo= rton; Marcelo Bagnulo Subject: New Version Notification for draft-eardley-lmap-terminology-01.txt A new version of I-D, draft-eardley-lmap-terminology-01.txt has been successfully submitted by Philip Eardley and posted to the IETF re= pository. Filename: draft-eardley-lmap-terminology Revision: 01 Title: Terminology for Large MeAsurement Platforms (LMAP) Creation date: 2013-05-02 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-eardley-lmap-ter= minology-01.txt Status: http://datatracker.ietf.org/doc/draft-eardley-lmap-termino= logy Htmlized: http://tools.ietf.org/html/draft-eardley-lmap-terminology-= 01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-eardley-lmap-term= inology-01 Abstract: This documents defines terminology for Large Scale Measurement Platforms. The IETF Secretariat _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_F1312FAF1A1E624DA0972D1C9A91379A1BFFE38AF8njfpsrvexg7re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1, Phil and Matt. I intended th= e reference path to be the basis for

discussions = like this, especially when seeking equivalent points

<= p class=3DMsoNormal>in different access technologies.

 =

Al

 =

From: lmap-bounces@ietf.org [ma= ilto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Wednesday, May 15, 2013 4:10 AM
To: mattmathis@google.= com
Cc: lmap@ietf.org
Subject: Re: [lmap] Missing conce= pt from draft-eardley-lmap-terminology-01.txt

 

<< I would like to have precise but technology indepe= ndent terms for the boundary between shared and unshared access resources&g= t;>

This se= ems a nice idea to me

 

As you say, different technologies have the shared/unshared boundary at d= ifferent distances from the customer. This means that great care is needed = if comparing results to the “sharing point” in two different ne= tworks

&n= bsp;

I also agree t= hat having a virtualised example would be good.

 

Ps think you’re referring to http://tools.ietf.= org/html/draft-morton-ippm-lmap-path-01 ? - though an open question whe= ther any of the terms from there should be migrated into http://tools.ietf.or= g/html/draft-eardley-lmap-terminology-01 – might be nice to have = them all in one place? Although organisationally one draft sits in ippm and= the other in lmap

 

T= hanks!
phil

 

From: Matt Mathis [mai= lto:mattmathis@google.com]
Sent: 13 May 2013 00:49
To:= Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org
Subject: Mi= ssing concept from draft-eardley-lmap-terminology-01.txt<= /p>

 

Most of the terminolog= y in this draft defined by routing and addressing concepts.   For meas= urement, it is also important to have terminology to describe traffic aggre= gation.  Especially important is over which subpaths might one custome= r's traffic be subject to resource contention with other customers?

 

I would like= to have precise but technology independent terms for the boundary between = shared and unshared access resources.   Note that for many technologie= s (mobile service, DOCSIS) this is very close to the service demarc at the = customer.  For others, such as FTTH and DSL it typically occurs in cen= tralized location.

 

The measurement problems on either side of this boundar= y are extremely different, and we need to be able to unambiguously make thi= s dichotomy.

 

I use "unshared access", "shared access",= and "sharing point."   Note that for many technologies the = sharing point is L2 or lower, so there might not a natural way to connect a= MP at the sharing point.

 

There is also the risk that addressing and routi= ng are going to become progressively less relevant as more and more of the = network becomes virtualized through such technologies as software defined n= etworks.    I consider ownership (responsibility), traffic aggreg= ation and resource contention to be far more important than addressing.

&= nbsp;

Al= so, "Destination host" is a rather odd choice for a content provi= der.   Perhaps "core service provider."


= Thanks,

= --MM--
The best way to predict the future is to create it.  - Alan = Kay

Privacy matters!  We know from recent events that people ar= e using our services to speak in defiance of unjust governments.   We = treat privacy and security as matters of life and death, because for some u= sers, they are.

 

On Thu, May 2, 2013 at 2:52 AM, = <philip.eardl= ey@bt.com> wrote:

I updated the draft http://tools.ietf.org/= html/draft-eardley-lmap-terminology
Thank-you for all the comments!<= br>
(the draft is a possible starting point for terminology for the pros= pective lmap wg)

Best wishes
phil

-----Original Message---= --
From: internet-drafts@iet= f.org [mailto:internet-draf= ts@ietf.org]
Sent: 02 May 2013 09:40
To: Al Morton; Eardley,PL,Ph= ilip,TUB8 R; Burbridge,T,Trevor,TUB8 R; Al C.Morton; Marcelo Bagnulo
Sub= ject: New Version Notification for draft-eardley-lmap-terminology-01.txt

A new version of I-D, draft-eardley-lmap-terminology-01.txt
has= been successfully submitted by Philip Eardley and posted to the IETF repos= itory.

Filename:        draft-eardley-lmap-termi= nology
Revision:        01
Title:     &= nbsp;     Terminology for Large MeAsurement Platforms (LMAP)
C= reation date:   2013-05-02
Group:          = ; Individual Submission
Number of pages: 10
URL:      =       http://www.ietf.org/inte= rnet-drafts/draft-eardley-lmap-terminology-01.txt
Status:   &nb= sp;      http://datatracker.ietf.org/doc/d= raft-eardley-lmap-terminology
Htmlized:        <= a href=3D"http://tools.ietf.org/html/draft-eardley-lmap-terminology-01" tar= get=3D"_blank">http://tools.ietf.org/html/draft-eardley-lmap-terminology-01=
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-eardley-lmap-terminology-01

Abstract:
   This documents defines terminology for L= arge Scale Measurement
   Platforms.




The IE= TF Secretariat

_______________________________________________
lm= ap mailing list
lmap@ietf.org
http= s://www.ietf.org/mailman/listinfo/lmap

 

=
= --_000_F1312FAF1A1E624DA0972D1C9A91379A1BFFE38AF8njfpsrvexg7re_-- From steing@ifi.uio.no Wed May 15 08:11:50 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DBF21F8F83; Wed, 15 May 2013 08:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGIrVo0PEbGg; Wed, 15 May 2013 08:11:45 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id E8FA821F8AD8; Wed, 15 May 2013 08:11:44 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UcdMl-0005Wl-5S; Wed, 15 May 2013 17:11:43 +0200 Received: from 1x-193-157-202-195.uio.no ([193.157.202.195]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user steing (Exim 4.80) (envelope-from ) id 1UcdMk-0004fY-EU; Wed, 15 May 2013 17:11:43 +0200 From: Stein Gjessing Content-Type: multipart/alternative; boundary="Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93" Date: Wed, 15 May 2013 17:11:41 +0200 Message-Id: To: aqm@ietf.org, rtcweb@ietf.org, lmap@ietf.org, tsvwg@ietf.org, rmcat@ietf.org, multipathtcp@ietf.org, video-codec@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 1 sum rcpts/h 13 sum msgs/h 4 total rcpts 2607 max rcpts/h 28 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.5, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.551, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 45A26AF8F0515C0711EDC4E4402EEAD2BB95E78D X-UiO-SPAM-Test: remote_host: 193.157.202.195 spam_score: -54 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 36 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: Stein Gjessing Subject: [lmap] CFP Packet Video 2013 - Special Session on Low-Latency Interactive Video X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:11:50 -0000 --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Here is an excellent venue for discussions and publication of results. Cheers,=20 Stein __________________________________________________________ Packet Video 2013 - Special Session on Low-Latency Interactive Video Sponsored by IEEE Communications Society December 12. and 13., 2013, San Jose, Ca, USA Call for papers. =20 http://pv2013.itec.aau.at/call-for-papers/accepted-special-sessions/#ss1 Several years ago, it was found that users do not like video quality = fluctuations. At that time the predominant belief was that network rate = fluctuations should be minimized, in order to reasonably interoperate = with TCP in the network. This led to the creation of a number of = so-called "TCP-friendly" congestion controls that exhibit a smoother = sending rate than TCP, while avoiding to send more than a conformant TCP = under similar conditions. TFRC is perhaps the best known example of such = a congestion control mechanism. A lot has happened since then: =95 The notion of TCP-friendliness has received massive = criticism; the widespread deployment of a more aggressive TCP variant, = CUBIC, has not led to an Internet meltdown, making the case that = diverging from strict TCP-friendliness is possible. =95 Latency minimization has become a major goal, especially in = the face of =93bufferbloat=94: large delays from large buffers with = simplistic FIFO-queue management. =95 Codecs have improved; novel video codecs are able to adjust = the data rate, but modern codecs may also produce variable bitrate = transmissions with burstier packet flows than before. =95 TFRC has been embedded in the DCCP protocol, which has = probably never been used for anything other than experiments; instead of = running over DCCP, RTP-based applications now contain proprietary = congestion control mechanisms. The emergence of the RTCWEB protocol suite for real-time communication = between Web browsers has renewed the interest in developing congestion = control standards for real-time media. This time, however, the goal is = to get things right: delay should be minimized, and standards should = realize congestion control using RTP with RTCP signaling. The IETF = =93Real-time Media Congestion Avoidance Techniques=94 (RMCAT) working = group has been founded to address this need. New questions arise: what = type of congestion controls do we need? How much feedback should we = send? How do we make this work in multi-user scenarios, e.g., for video = conferencing? What should be the API between a video codec and a new = delay-based congestion controlled RTP stream? What is the quality that = can be expected from the combination of a codec and congestion control = mechanism, when we consider better metrics than plain PSNR? Topics of interest include, but are not limited to: =95 Congestion control algorithms for interactive real-time = video: requirements, evaluation criteria, and mechanisms =95 Necessary RTP/RTCP extensions =95 Field experience with video codecs in a low-delay, real-time = setting =95 Interactions between applications and RTP flows =95 Failing to meet real-time schedules: impact, techniques to = detect, instrument or diagnose it Organizers: =95 Michael Welzl, University of Oslo (michawe at ifi.uio.no) =95 Stein Gjessing, University of Oslo (steing at ifi.uio.no)= --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://pv2013.itec.aau.at/call-for-papers/accepted-special-session= s/#ss1

Several years ago, it was found that users do not like = video quality fluctuations. At that time the predominant belief was that = network rate fluctuations should be minimized, in order to reasonably = interoperate with TCP in the network. This led to the creation of a = number of so-called "TCP-friendly" congestion controls that exhibit a = smoother sending rate than TCP, while avoiding to send more than a = conformant TCP under similar conditions. TFRC is perhaps the best known = example of such a congestion control mechanism.

A lot has = happened since then:
=95 The notion of = TCP-friendliness has received massive criticism; the widespread = deployment of a more aggressive TCP variant, CUBIC, has not led to an = Internet meltdown, making the case that diverging from strict = TCP-friendliness is possible.
=95 Latency minimization has = become a major goal, especially in the face of =93bufferbloat=94: large = delays from large buffers with simplistic FIFO-queue = management.
=95 TFRC = has been embedded in the DCCP protocol, which has probably never been = used for anything other than experiments; instead of running over DCCP, = RTP-based applications now contain proprietary congestion control = mechanisms.

The emergence of the RTCWEB protocol suite for = real-time communication between Web browsers has renewed the interest in = developing congestion control standards for real-time media. This time, = however, the goal is to get things right: delay should be minimized, and = standards should realize congestion control using RTP with RTCP = signaling. The IETF =93Real-time Media Congestion Avoidance Techniques=94 = (RMCAT) working group has been founded to address this need. New = questions arise: what type of congestion controls do we need? How much = feedback should we send? How do we make this work in multi-user = scenarios, e.g., for video conferencing? What should be the API between = a video codec and a new delay-based congestion controlled RTP stream? = What is the quality that can be expected from the combination of a codec = and congestion control mechanism, when we consider better metrics than = plain PSNR?

Topics of interest include, but are not limited = to:
= =95 Congestion control algorithms for interactive real-time = video: requirements, evaluation criteria, and mechanisms
=95 = Necessary RTP/RTCP extensions
=95 Field experience with video = codecs in a low-delay, real-time setting
=95 Interactions between = applications and RTP flows
=95 Failing to meet real-time = schedules: impact, techniques to detect, instrument or diagnose = it

Organizers:
=95 Michael Welzl, University of = Oslo (michawe at ifi.uio.no)
=95 Stein = Gjessing, University of Oslo (steing at ifi.uio.no)
= --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93-- From mattmathis@google.com Wed May 15 08:32:02 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CD521F908B for ; Wed, 15 May 2013 08:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.777 X-Spam-Level: X-Spam-Status: No, score=-100.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1FhnjXx6f+W for ; Wed, 15 May 2013 08:32:01 -0700 (PDT) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 13A4621F905C for ; Wed, 15 May 2013 08:31:59 -0700 (PDT) Received: by mail-ia0-f176.google.com with SMTP id m19so2027150iah.7 for ; Wed, 15 May 2013 08:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mtjLAcmzQOyQO/D3JZieBKhVT2YJNz4v1Cm7USxmqpc=; b=ZG2gAM/iCQvYvWEcTGJC2vs0X2oKy7jpnL+9mf/SWEzMa1MOviDONOHoWVYNmr6WN5 L4aOu+MFbjXhh5lD+H3iSp+XypvKgHvPugq2LVsPr0cfnVD6wWv+Yr4DeLsoZR8dqSPw NeSRf0L+aGfSuBia5BvTkpii4x3mihzZeRfEN7JMcpoqu3jujrYxIKm4WruC2GRn+oVX tY0LAibJT4+OcJM3a4Jx7PgqYJn45Osx4ViFhn+rk/rqSb4N/OTmVBCA97oomVA+WMbM 8w/oG1SDEQk+kBHOy2zLja8Lq/g/B+K1ZbK4gJQd8bqMpVC7EHiqL/K8D6nDZQTLSNW4 ehBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=mtjLAcmzQOyQO/D3JZieBKhVT2YJNz4v1Cm7USxmqpc=; b=mHh/EUnqU3+HRy8iHttPW0rHmso7U1MNDnDuqYcv0OleatbbqUdFOo7DhFqAmOSCub jE8MfismkJdc1+OBDyBjyzRpN6LQoRySPcXJsK07nh29uM/+0pR3m338AazR7KT6qHzu litfQHBmEcjNw6AkCyoGXbC1+1iYNizLAVmsK9nvBnCF5r+YIrBMyvg9OcLHgeCccv+8 EvtpxQRwXY04DsQi+vggjSSB7yVPZH/fPn8OaVfZrdO/vaiEywxAfgYYeICN8wAxewWT 1Onjj7FWqyGrOk/rxVfY4o4JxKzdpEwS+rXvUzjVHcUetEKlAi1kPTtMNIhaIfjrMJAB 6ZdQ== MIME-Version: 1.0 X-Received: by 10.50.66.197 with SMTP id h5mr5747471igt.63.1368631919555; Wed, 15 May 2013 08:31:59 -0700 (PDT) Received: by 10.64.44.201 with HTTP; Wed, 15 May 2013 08:31:59 -0700 (PDT) In-Reply-To: <9510D26531EF184D9017DF24659BB87F347540758F@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F347540758F@EMV65-UKRD.domain1.systemhost.net> Date: Wed, 15 May 2013 08:31:59 -0700 Message-ID: From: Matt Mathis To: "EARDLEY, Phil" Content-Type: multipart/alternative; boundary=047d7bd6be0e64d66504dcc37345 X-Gm-Message-State: ALoCoQmKz5XEjRTCX+aOYUZ6S6PwNEINOy12ZL6cSgFGvZcsjKZc1VuBHoTUHwhR/lAm7y5NDo0HrjFkZYqEuCUe047rPByWinDAlY7DLbZBdqKbIcQdgf1QvIEXVL/2hKAfauvNrhxnQ12qpSFg84JUeFaCqGLKqrk07yR+PSoqUy4TaqD4Y5pKP/vwppvQPU5+BANQ6PRX Cc: "lmap@ietf.org" Subject: Re: [lmap] Missing concept from draft-eardley-lmap-terminology-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:32:02 -0000 --047d7bd6be0e64d66504dcc37345 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Oops, You are correct, I was looking at -ippm-lmap-path-, and not -terminology. My bad I am not as interested in comparisons between ISPs using different technologies as I am in having methodology that most accurately portrays each portion of the path. Consider issues of cross traffic: for the unshared portion of the path it is important to test when the user is not using their service, so I can measure the raw capacity of their access link. For the shared portion of the path, I am typically more interested in precisely the opposite question - does the ISP have sufficient capacity to carry their aggregate load under normal conditions. My measurement strategy is to somehow place a real or virtual MP at the aggregation point, and measure the performance between an external MP and the aggregation point, under actual load. For the shared portion of the path, excluding data points due to load is precisely the wrong thing to do, and raises questions about sampling bias if the virtual MP is actually placed on a subscriber's premise, and data has to be discarded when the subscriber is active. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Wed, May 15, 2013 at 1:10 AM, wrote: > << I would like to have precise but technology independent terms for the > boundary between shared and unshared access resources>>**** > > This seems a nice idea to me**** > > ** ** > > As you say, different technologies have the shared/unshared boundary at > different distances from the customer. This means that great care is need= ed > if comparing results to the =93sharing point=94 in two different networks= **** > > ** ** > > I also agree that having a virtualised example would be good.**** > > ** ** > > Ps think you=92re referring to > http://tools.ietf.org/html/draft-morton-ippm-lmap-path-01 ? - though an > open question whether any of the terms from there should be migrated into > http://tools.ietf.org/html/draft-eardley-lmap-terminology-01 =96 might be > nice to have them all in one place? Although organisationally one draft > sits in ippm and the other in lmap **** > > ** ** > > Thanks! > phil**** > > ** ** > > *From:* Matt Mathis [mailto:mattmathis@google.com] > *Sent:* 13 May 2013 00:49 > *To:* Eardley,PL,Philip,TUB8 R > *Cc:* lmap@ietf.org > *Subject:* Missing concept from draft-eardley-lmap-terminology-01.txt**** > > ** ** > > Most of the terminology in this draft defined by routing and addressing > concepts. For measurement, it is also important to have terminology to > describe traffic aggregation. Especially important is over which subpath= s > might one customer's traffic be subject to resource contention with other > customers?**** > > ** ** > > I would like to have precise but technology independent terms for the > boundary between shared and unshared access resources. Note that for ma= ny > technologies (mobile service, DOCSIS) this is very close to the service > demarc at the customer. For others, such as FTTH and DSL it typically > occurs in centralized location.**** > > ** ** > > The measurement problems on either side of this boundary are extremely > different, and we need to be able to unambiguously make this dichotomy.**= * > * > > ** ** > > I use "unshared access", "shared access", and "sharing point." Note tha= t > for many technologies the sharing point is L2 or lower, so there might no= t > a natural way to connect a MP at the sharing point.**** > > ** ** > > There is also the risk that addressing and routing are going to become > progressively less relevant as more and more of the network becomes > virtualized through such technologies as software defined networks. I > consider ownership (responsibility), traffic aggregation and resource > contention to be far more important than addressing.**** > > ** ** > > Also, "Destination host" is a rather odd choice for a content provider. > Perhaps "core service provider."**** > > > **** > > Thanks,**** > > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat privacy a= nd > security as matters of life and death, because for some users, they are.*= * > ** > > ** ** > > On Thu, May 2, 2013 at 2:52 AM, wrote:**** > > I updated the draft > http://tools.ietf.org/html/draft-eardley-lmap-terminology > Thank-you for all the comments! > > (the draft is a possible starting point for terminology for the > prospective lmap wg) > > Best wishes > phil > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 02 May 2013 09:40 > To: Al Morton; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; Al > C.Morton; Marcelo Bagnulo > Subject: New Version Notification for draft-eardley-lmap-terminology-01.t= xt > > > A new version of I-D, draft-eardley-lmap-terminology-01.txt > has been successfully submitted by Philip Eardley and posted to the IETF > repository. > > Filename: draft-eardley-lmap-terminology > Revision: 01 > Title: Terminology for Large MeAsurement Platforms (LMAP) > Creation date: 2013-05-02 > Group: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-eardley-lmap-terminology-01.txt > Status: > http://datatracker.ietf.org/doc/draft-eardley-lmap-terminology > Htmlized: > http://tools.ietf.org/html/draft-eardley-lmap-terminology-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-eardley-lmap-terminology-01 > > Abstract: > This documents defines terminology for Large Scale Measurement > Platforms. > > > > > The IETF Secretariat > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap**** > > ** ** > --047d7bd6be0e64d66504dcc37345 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Oops, You are correct, I was looking at -ippm-lmap-path-, = and not -terminology. =A0My bad

I am not as interested i= n comparisons between ISPs using different=A0technologies=A0as I am in havi= ng methodology that most accurately portrays each portion of the path.

Consider issues of cross traffic: for the unshared port= ion of the path it is important to test when the user is not using their se= rvice, so I can measure the raw capacity of their access link. =A0 For the = shared portion of the path, I am typically more interested in=A0precisely= =A0the=A0opposite question=A0- does the ISP have sufficient capacity to car= ry their aggregate load under normal conditions. =A0 My measurement=A0strat= egy=A0is to somehow place a real or virtual MP at the aggregation point, an= d measure the performance between an external MP and the aggregation=A0poin= t, under actual load.

For the shared portion of the path, excluding data poin= ts due to load is=A0precisely=A0the wrong thing to do, and raises questions= about sampling bias if the virtual MP is actually placed on a subscriber&#= 39;s premise, and data has to be=A0discarded=A0when the subscriber is activ= e.

Thanks= ,
--MM--
The best way to predict the future is to create it. =A0- A= lan Kay

Privacy matters! =A0We know from recent events that people a= re using our services to speak in defiance of unjust governments. =A0 We tr= eat privacy and security as matters of life and death, because for some use= rs, they are.


On Wed, May 15, 2013 at 1:10 AM, <= philip.eardley@bt.com> wrote:

<< I would like to have precise but technology i= ndependent terms for the boundary between shared and unshared access resour= ces>>

This seems a nice idea to me

=

=A0

As you s= ay, different technologies have the shared/unshared boundary at different d= istances from the customer. This means that great care is needed if compari= ng results to the =93sharing point=94 in two different networks

=A0

I also a= gree that having a virtualised example would be good.

=A0

Ps think you= =92re referring to http://tools.ietf.org/html/draft-morton-ipp= m-lmap-path-01 ? - though an open question whether any of the terms fro= m there should be migrated into http://tools.ietf.org/html/= draft-eardley-lmap-terminology-01 =96 might be nice to have them all in= one place? Although organisationally one draft sits in ippm and the other = in lmap

=A0

Thanks!<= br>phil

=A0=

From: Matt Mathis [mailto:mattmathis@google.com]=
Sent: 13 May 2013 00:49
To: Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org
Subject: Missing concept from draft-eardley-lmap-terminology-0= 1.txt

=A0

Most of the terminology in this draft defined by routing= and addressing concepts. =A0 For measurement, it is also important to have= terminology to describe traffic aggregation. =A0Especially important is ov= er which subpaths might one customer's traffic be subject to resource c= ontention with other customers?

=A0

I would like to have precise but technology independent terms for t= he boundary between shared and unshared access resources. =A0 Note that for= many technologies (mobile service, DOCSIS) this is very close to the servi= ce demarc at the customer. =A0For others, such as FTTH and DSL it typically= occurs in centralized location.

=A0

The measurement problems on either side of this boundary are= extremely different, and we need to be able to unambiguously make this dic= hotomy.

=A0

I use "unshared access", "shared access"= , and "sharing point." =A0 Note that for many technologies the sh= aring point is L2 or lower, so there might not a natural way to connect a M= P at the sharing point.

=A0

There is also the risk that addressing and routing are going= to become progressively less relevant as more and more of the network beco= mes virtualized through such technologies as software defined networks. =A0= =A0I consider ownership (responsibility), traffic aggregation and resource= contention to be far more important than addressing.

=A0

Also, "Destination host" is a rather odd choice fo= r a content provider. =A0 Perhaps "core service provider."=


=

Thanks,

--MM--
The best way to predict the future is to create = it. =A0- Alan Kay

Privacy matters! =A0We know from recent events that people are using ou= r services to speak in defiance of unjust governments. =A0 We treat privacy= and security as matters of life and death, because for some users, they ar= e.

= =A0

On Thu, May 2, 2013 at 2:52 AM, &= lt;philip.eardle= y@bt.com> wrote:

I updated the draft http://too= ls.ietf.org/html/draft-eardley-lmap-terminology
Thank-you for all th= e comments!

(the draft is a possible starting point for terminology for the prospec= tive lmap wg)

Best wishes
phil

-----Original Message-----<= br>From: inte= rnet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: 02 May 2013 09:40
To: Al Morton; Eardley,PL,Philip,TUB8 R; Burbrid= ge,T,Trevor,TUB8 R; Al C.Morton; Marcelo Bagnulo
Subject: New Version No= tification for draft-eardley-lmap-terminology-01.txt


A new versi= on of I-D, draft-eardley-lmap-terminology-01.txt
has been successfully submitted by Philip Eardley and posted to the IETF re= pository.

Filename: =A0 =A0 =A0 =A0draft-eardley-lmap-terminologyRevision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Terminology for = Large MeAsurement Platforms (LMAP)
Creation date: =A0 2013-05-02
Group: =A0 =A0 =A0 =A0 =A0 Individual Subm= ission
Number of pages: 10
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-eardley-lmap-term= inology-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/do= c/draft-eardley-lmap-terminology
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-eardley-lmap-terminology-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rf= cdiff?url2=3Ddraft-eardley-lmap-terminology-01

Abstract:
=A0 = =A0This documents defines terminology for Large Scale Measurement
=A0 =A0Platforms.




The IETF Secretariat

__________= _____________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.o= rg/mailman/listinfo/lmap

=A0

<= /div>

--047d7bd6be0e64d66504dcc37345-- From acmorton@att.com Wed May 22 08:40:14 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F3521F880F for ; Wed, 22 May 2013 08:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.309 X-Spam-Level: X-Spam-Status: No, score=-106.309 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPtXAZMg7RDh for ; Wed, 22 May 2013 08:40:09 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id B618D21F8491 for ; Wed, 22 May 2013 08:39:47 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id DA64E120336; Wed, 22 May 2013 11:39:46 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id 5E58AF0362; Wed, 22 May 2013 11:39:47 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Wed, 22 May 2013 11:39:47 -0400 From: "MORTON JR., ALFRED C (AL)" To: Benoit Claise , Dan Romascanu , "lmap@ietf.org" Date: Wed, 22 May 2013 11:39:45 -0400 Thread-Topic: charter discussion status Thread-Index: Ac5QkBlfK3L5NZQjQTCN3cU5EfJ1YQGcBVfg Message-ID: References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> In-Reply-To: <51921584.8040505@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:40:14 -0000 > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Tuesday, May 14, 2013 6:44 AM > To: MORTON JR., ALFRED C (AL); Dan Romascanu; lmap@ietf.org > Subject: Re: charter discussion status >=20 > Hi J=FCergen, >=20 > Timely question. > As far as I'm concerned, the couple of clarifying questions I asked on > the mailing list are now addressed. > Al, Dan, and I are working on the charter proposal. > You can expect some charter proposal very soon. >=20 > Regards, Benoit >=20 The "first" draft charter text is appended below. It would be ideal if readers could hold-off on nit-level comments and post the most significant issues first (but we won't try to achieve consensus on significance). You get points for suggesting editorial improvements, but please send them to Dan and Al, not the list. And last, let us suggest that commenters take the extra time necessary to=20 write a brief message when posting to the list. All subscribers will=20 appreciate your efforts. regards, Dan and Al -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Name: Large-Scale Measurement of Broadband Performance (LMAP) AREA: Operations and Management Chairs: TBD TBD OPS Area Directors: =20 Benoit Claise Joel Jaeggli OPS Area Advisor: Benoit Claise Mailing Lists: General Discussion: lmap at ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/lmap Archive: http://www.ietf.org/mail-archive/web/lmap Description of Working Group Measuring portions of the Internet on a large scale is vital for=20 accurate characterizations of performance over time and geography, for=20 network diagnostic investigations by providers and their users, and for=20 collecting information to support public policy development. The=20 ultimate goal is to have the same measurements for a large number of=20 points on the Internet, conducted according to the same=20 characterization plan, and to have the results collected and stored in=20 the same form.=20 Many measurement systems that exist today use proprietary,=20 custom-designed mechanisms to coordinate their Measurement Agents (MAs)=20 deployed across networks, to communicate between MAs and measurement=20 Controllers, and to transfer results to measurement Collectors.=20 Standardizing these mechanisms (Control protocol, Report protocol,=20 and corresponding data models) will make it possible to incorporate=20 interoperable measurement communications into home and enterprise=20 edge routers, personal computers, mobile devices and other networking=20 devices, whether wired or wireless. Standards will help these management=20 capabilities become more pervasive and facilitate measurement results=20 that are directly comparable. The Large-Scale Measurement of Broadband Performance (LMAP) working=20 group is chartered to determine the form of data models and=20 select/extend one or more protocols for the communications between the=20 Measurement Agents' (MAs) function and their Controller function and=20 Collector function. These three functions comprise the LMAP measurement=20 system. The standardized LMAP mechanisms will allow a Controller to instruct=20 MAs what performance metrics to measure, when to measure them, and=20 how/when to report the measurement results to a Collector. The primary=20 products of the working group are the data models that define the=20 measurement instructions and reports, and protocols for securely=20 delivering these data models to/from the MAs. Data models should be=20 extensible for new and additional measurements. A key assumption constraining the initial work is that the measurement=20 system is under the control of a single organization (for example, an=20 Internet Service Provider or a regulator). However, the components of=20 an LMAP measurement system can be deployed in administrative domains=20 that are not owned by the measuring organization. Thus, the system of=20 functions deployed by a single organization constitutes a single LMAP=20 domain which may span ownership or other administrative boundaries.=20 The LMAP architecture will allow for measurements that utilize either=20 IPv4 or IPv6, or possibly both. Devices containing MAs may have several=20 interfaces using different link technologies. Multiple address families=20 and interfaces must be considered in the Control and Reporting=20 protocols. It is assumed that different organization's LMAP measurement domains=20 can overlap, and that active measurement packets appear along with=20 normal user traffic when crossing another organization's network. In=20 the initial chartering phase, there is no requirement to specify a=20 mechanism for coordination between the LMAP measurements in overlapping=20 domains (for instance a home network with MAs on the home hub, set top=20 box and laptop). In principle, there are no restrictions on the type of=20 device in which the MA function resides.=20 Both active and passive measurements are in scope, although there may=20 be differences in their applicability to specific use cases, or in the=20 security measures needed according to the threats specific to each=20 measurement category. At a high level, LMAP systems are agnostic to the=20 measurements and results, and extensible to incorporate evolution in=20 the measurement area, but the details such as the data models must be=20 standardized to match the measurements. Inter-organization communication of results is a consideration not=20 addressed in the LMAP system and deferred to bi-lateral agreements. Many measurement aspects are already within the charter of IPPM. These=20 include standardized definitions of performance metrics, MA-to-MA=20 measurement protocols, and a registry of frequently-used metrics and=20 parameter settings so they can be identified in an efficient and=20 consistent fashion. Neither the definition of the new metrics and=20 methods of measurement, nor the post-processing and analysis of results=20 falls within the remit of LMAP.=20 The case where an end user can independently perform network diagnostic=20 measurements (beyond their private network) is not directly in scope,=20 recognizing that users have many opportunities to do this today.=20 However, end users can obtain an MA to run measurement tasks if desired=20 and report their results to whomever they want, most likely the=20 supplier of the MA. This provides for user-initiated on-demand=20 measurement, which is an important component of the ISP use case. Another area that is out of scope is the management protocol to=20 bootstrap the MAs in measurement devices, although a bootstrapping=20 process may be described and conducted in many ways, such as=20 configuration during manufacture or with a local USB interface.=20 Discovering the service parameters on the MAs or sharing the service=20 parameters between MAs are out of the scope of the LMAP charter.=20 However, if the service parameters are available to the MAs, they could=20 be combined with the measurement results in the Report Protocol. Service parameters can be used to decide which measurements to run, or=20 to interpret the results (for example, when assigning the correct=20 product categorization). These parameters are already gathered and=20 stored by existing operations systems. Deciding the set of measurements=20 to run is a business decision and is out of scope. =20 Exhaustive protection against all possibilities of gaming the=20 measurements - where gaming is defined as intentionally (and perhaps=20 maliciously) inserting inaccuracy into the overall system or=20 measurement process - is beyond the scope of work. Some protections are=20 lawyer problems, not engineering problems. However, the working group=20 may include protections that do not add significant complexity, as=20 determined by working group consensus. The LMAP working group will coordinate with other standards bodies=20 working in this area (e.g., BBF, IEEE 802.16, ETSI), and other IETF=20 working groups in the areas of data models, protocols, multiple=20 interface management, and measurement of performance metrics. LMAP will consider re-use of existing protocols and data model=20 languages in its efforts to produce the following work items: - The LMAP Framework - provides common terminology and justifies the=20 simplifying constraints=20 - The LMAP Use Cases - provides the motivating use cases as a basis for=20 the work=20 - Information Models, the abstract definition of the measurement tasks=20 and the Report; the semantics of the fields and their arrangement (the=20 order they appear in and any hierarchy). - A Data model that defines how the Controller tells an MA to execute a=20 measurement instruction. It includes the metric(s) to be measured and=20 values for its parameters such as the Peer MA participating in the=20 measurement and the desired environmental conditions (for example, only=20 conduct the measurement when there is no user traffic observed). It=20 also includes the schedule (when the measurement should be run) and how=20 the results should be reported (when and to which Collector).=20 - A Data model that defines the report that the MA sends to the=20 Collector. It includes the metric(s) measured and when, the actual=20 result, and supporting metadata such as location. Results reports may=20 be organized in batches or may be reported immediately, such as for an=20 on-demand measurement.=20 - The Control protocol: The definition of how instructions are=20 delivered from a Controller to a MA; a Data Model plus a transport=20 protocol. This is a simple instruction - response protocol, and LMAP=20 will specify how it operates over an existing protocol (to be selected,=20 perhaps REST-style HTTP(s) or Netconf).=20 - The Report protocol: The definition of how the Report is delivered=20 from a MA to a Collector; a Data Model plus a transport protocol (to be=20 selected, possibly IPFIX). Goals and Milestones Sep 2013: Initial WG I-D for the LMAP Framework including terminology=20 Sep 2013: Initial WG I-D for the LMAP Use cases Dec 2013: Submit the LMAP Framework I-D to the IESG for consideration=20 as Informational RFC Dec 2013: Submit I-D on the LMAP Use cases to the IESG for=20 consideration as Informational RFC Jan 2014: Initial WG I-D for LMAP Information models Jan 2014: Initial WG I-D for the Control protocol=20 Jan 2014: Initial WG I-D for the Report protocol=20 Apr 2014: Initial WG I-D for a Data model for LMAP control information Apr 2014: Initial WG I-D for a Data model for LMAP report information July 2014: Submit the LMAP Information models I-D to the IESG for=20 consideration as Standards track RFC July 2014: Submit the Control protocol I-D to the IESG for=20 consideration as Standards track RFC July 2014: Submit Report protocol I-D to the IESG for consideration as=20 Standards track RFC Dec 2014: Submit the Data model for LMAP control I-D to the IESG for=20 consideration as Standards track RFC Dec 2014: Submit the Data model for LMAP report I-D to the IESG for=20 consideration as Standards track RFC From j.schoenwaelder@jacobs-university.de Wed May 22 13:11:52 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFD511E80F9 for ; Wed, 22 May 2013 13:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.163 X-Spam-Level: X-Spam-Status: No, score=-103.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czO0j81uFZTg for ; Wed, 22 May 2013 13:11:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF7921F925B for ; Wed, 22 May 2013 13:11:44 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DDBB20BF0; Wed, 22 May 2013 22:11:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ofh40ielUtgG; Wed, 22 May 2013 22:11:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B69C720BEE; Wed, 22 May 2013 22:11:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6DC5E266D7DE; Wed, 22 May 2013 22:11:41 +0200 (CEST) Date: Wed, 22 May 2013 22:11:41 +0200 From: Juergen Schoenwaelder To: "MORTON JR., ALFRED C (AL)" Message-ID: <20130522201141.GA30745@elstar.local> Mail-Followup-To: "MORTON JR., ALFRED C (AL)" , Benoit Claise , Dan Romascanu , "lmap@ietf.org" References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Benoit Claise , Dan Romascanu , "lmap@ietf.org" Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 20:11:52 -0000 On Wed, May 22, 2013 at 11:39:45AM -0400, MORTON JR., ALFRED C (AL) wrote: > It would be ideal if readers could hold-off on nit-level comments > and post the most significant issues first (but we won't try to achieve > consensus on significance). [...] > - Information Models, the abstract definition of the measurement tasks > and the Report; the semantics of the fields and their arrangement (the > order they appear in and any hierarchy). > - A Data model that defines how the Controller tells an MA to execute a > measurement instruction. It includes the metric(s) to be measured and > values for its parameters such as the Peer MA participating in the > measurement and the desired environmental conditions (for example, only > conduct the measurement when there is no user traffic observed). It > also includes the schedule (when the measurement should be run) and how > the results should be reported (when and to which Collector). > - A Data model that defines the report that the MA sends to the > Collector. It includes the metric(s) measured and when, the actual > result, and supporting metadata such as location. Results reports may > be organized in batches or may be reported immediately, such as for an > on-demand measurement. > - The Control protocol: The definition of how instructions are > delivered from a Controller to a MA; a Data Model plus a transport > protocol. This is a simple instruction - response protocol, and LMAP > will specify how it operates over an existing protocol (to be selected, > perhaps REST-style HTTP(s) or Netconf). > - The Report protocol: The definition of how the Report is delivered > from a MA to a Collector; a Data Model plus a transport protocol (to be > selected, possibly IPFIX). The phrase 'fields and their arrangement (the order they appear in and any hierarchy)' should be something like 'fields and their relationships'. It would be wrong to prescribe certain hierarchical nestings since protocols may have different constraints there. The first item is an information model. This is fine. The second and third items are data models. I would argue that the details what should be cover should be moved to the information model - the data models simply have to consistent with the information model. The fourth and fifth items talk about protocols and once again data models. This means confusing overlap. To sum up, here is a significantly simplified version: - Information Model, the abstract definition of the information carried from the Controller to the MA and the information carried from the MA to the Collector. It includes the metric(s) to be measured and values for its parameters such as the Peer MA participating in the measurement and the desired environmental conditions (for example, only conduct the measurement when there is no user traffic observed). It also includes the schedule (when the measurement should be run) and how the results should be reported (when and to which Collector). It further includes the metric(s) measured and when, the actual result, and supporting metadata such as location. Result reports may be organized in batches or may be reported immediately, such as for an on-demand measurement. - The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus a transport protocol. This is a simple instruction - response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). - The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). Sorry for the length of this message. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From acmorton@att.com Wed May 22 13:50:57 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9610D21F8F69 for ; Wed, 22 May 2013 13:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.345 X-Spam-Level: X-Spam-Status: No, score=-106.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhL-VHJFz5gG for ; Wed, 22 May 2013 13:50:44 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC1D21F8F4A for ; Wed, 22 May 2013 13:50:44 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 7C366120481; Wed, 22 May 2013 16:50:42 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id 060AEF0366; Wed, 22 May 2013 16:50:43 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Wed, 22 May 2013 16:50:42 -0400 From: "MORTON JR., ALFRED C (AL)" To: Juergen Schoenwaelder Date: Wed, 22 May 2013 16:50:41 -0400 Thread-Topic: [lmap] charter discussion status Thread-Index: Ac5XKJzd1JYx0yKZQiGhCQyJkO3GkgAA2o3g Message-ID: References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> <20130522201141.GA30745@elstar.local> In-Reply-To: <20130522201141.GA30745@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 Cc: Benoit Claise , Dan Romascanu , "lmap@ietf.org" Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 20:50:57 -0000 Thanks for your suggestion of revised text, Juergen. When you go to the trouble of clarifying sections by re-writing them, there's no limit on message length, and excerpted text doesn't count. ;-) Taking it a step further, does your proposal to emphasize the Information Model obviate the separate memos on the Control and Reporting Data Models, and thus we should remove them from the milestones, or is the non-abstract expression of each Data Model useful to keep separate from the Protocol mem= os? Al > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, May 22, 2013 4:12 PM ... >=20 > The phrase 'fields and their arrangement (the order they appear in and > any hierarchy)' should be something like 'fields and their > relationships'. It would be wrong to prescribe certain hierarchical > nestings since protocols may have different constraints there. >=20 > The first item is an information model. This is fine. The second and > third items are data models. I would argue that the details what > should be cover should be moved to the information model - the data > models simply have to consistent with the information model. The > fourth and fifth items talk about protocols and once again data > models. This means confusing overlap. >=20 > To sum up, here is a significantly simplified version: >=20 > - Information Model, the abstract definition of the information carried > from the Controller to the MA and the information carried from the MA > to the Collector. It includes the metric(s) to be measured and > values for its parameters such as the Peer MA participating in the > measurement and the desired environmental conditions (for example, only > conduct the measurement when there is no user traffic observed). It > also includes the schedule (when the measurement should be run) and how > the results should be reported (when and to which Collector). It > further includes the metric(s) measured and when, the actual > result, and supporting metadata such as location. Result reports may > be organized in batches or may be reported immediately, such as for an > on-demand measurement. > - The Control protocol and the associated data model: The definition of > how instructions are delivered from a Controller to a MA; this > includes a Data Model consistent with the Information Model plus a > transport protocol. This is a simple instruction - response > protocol, and LMAP will specify how it operates over an existing > protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). > - The Report protocol and the associated data model: The definition of > how the Report is delivered from a MA to a Collector; this includes > a Data Model consistent with the Information Model plus a transport > protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). >=20 > Sorry for the length of this message. >=20 > /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 dromasca@avaya.com Thu May 23 00:13:39 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FB621F96DE for ; Thu, 23 May 2013 00:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzlHsT-A8q9g for ; Thu, 23 May 2013 00:13:34 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D654921F971A for ; Thu, 23 May 2013 00:13:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusFAOvAnVGHCzI1/2dsb2JhbABXA4JnITDCJIEJFnSCIwEBAQEDEigtCwcMAgICAQgNAQIBBAEBAQoUCQcbFxQJCAIEDgUIGodrAZ5knB8EjmghEAcGC4JiYQOTZ4R6hRiKf4MPgiY X-IronPort-AV: E=Sophos;i="4.87,726,1363147200"; d="scan'208";a="10355939" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 May 2013 03:13:13 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 May 2013 03:09:05 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Thu, 23 May 2013 03:13:11 -0400 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "MORTON JR., ALFRED C (AL)" Thread-Topic: [lmap] charter discussion status Thread-Index: AQHOVyiWJb/q7dYgAUmTk/qX3ZjWTZkSWriw Date: Thu, 23 May 2013 07:13:10 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA175301@AZ-FFEXMB04.global.avaya.com> References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> <20130522201141.GA30745@elstar.local> In-Reply-To: <20130522201141.GA30745@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 07:13:40 -0000 This looks good to me.=20 May I suggest a slight reorganization of the Information Model bullet to av= oid the repetition of 'it includes':=20 - Information Model, the abstract definition of the information carried from the Controller to the MA and the information carried from the MA to the Collector. It includes=20 - the metric(s) to be measured and values for its parameters such as the Peer MA participating in the measurement and the desired environmental conditions (for example, only conduct the measurement when there is no user traffic observed)=20 - the schedule (when the measurement should be run) and how the results should be reported (when and to which Collector) - the metric(s) measured and when, the actual result, and supporting metadata such as location. Result reports may=20 be organized in batches or may be reported immediately, such as for an on-demand measurement. Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, May 22, 2013 11:12 PM > To: MORTON JR., ALFRED C (AL) > Cc: Benoit Claise; Romascanu, Dan (Dan); lmap@ietf.org > Subject: Re: [lmap] charter discussion status >=20 > On Wed, May 22, 2013 at 11:39:45AM -0400, MORTON JR., ALFRED C (AL) > wrote: >=20 > > It would be ideal if readers could hold-off on nit-level comments and > > post the most significant issues first (but we won't try to achieve > > consensus on significance). >=20 > [...] >=20 > > - Information Models, the abstract definition of the measurement tasks > > and the Report; the semantics of the fields and their arrangement (the > > order they appear in and any hierarchy). > > - A Data model that defines how the Controller tells an MA to execute > > a measurement instruction. It includes the metric(s) to be measured > > and values for its parameters such as the Peer MA participating in the > > measurement and the desired environmental conditions (for example, > > only conduct the measurement when there is no user traffic observed). > > It also includes the schedule (when the measurement should be run) and > > how the results should be reported (when and to which Collector). > > - A Data model that defines the report that the MA sends to the > > Collector. It includes the metric(s) measured and when, the actual > > result, and supporting metadata such as location. Results reports may > > be organized in batches or may be reported immediately, such as for an > > on-demand measurement. > > - The Control protocol: The definition of how instructions are > > delivered from a Controller to a MA; a Data Model plus a transport > > protocol. This is a simple instruction - response protocol, and LMAP > > will specify how it operates over an existing protocol (to be > > selected, perhaps REST-style HTTP(s) or Netconf). > > - The Report protocol: The definition of how the Report is delivered > > from a MA to a Collector; a Data Model plus a transport protocol (to > > be selected, possibly IPFIX). >=20 > The phrase 'fields and their arrangement (the order they appear in and > any hierarchy)' should be something like 'fields and their > relationships'. It would be wrong to prescribe certain hierarchical > nestings since protocols may have different constraints there. >=20 > The first item is an information model. This is fine. The second and > third items are data models. I would argue that the details what should > be cover should be moved to the information model - the data models > simply have to consistent with the information model. The fourth and > fifth items talk about protocols and once again data models. This means > confusing overlap. >=20 > To sum up, here is a significantly simplified version: >=20 > - Information Model, the abstract definition of the information carried > from the Controller to the MA and the information carried from the MA > to the Collector. It includes the metric(s) to be measured and > values for its parameters such as the Peer MA participating in the > measurement and the desired environmental conditions (for example, > only > conduct the measurement when there is no user traffic observed). It > also includes the schedule (when the measurement should be run) and > how > the results should be reported (when and to which Collector). It > further includes the metric(s) measured and when, the actual > result, and supporting metadata such as location. Result reports may > be organized in batches or may be reported immediately, such as for an > on-demand measurement. > - The Control protocol and the associated data model: The definition of > how instructions are delivered from a Controller to a MA; this > includes a Data Model consistent with the Information Model plus a > transport protocol. This is a simple instruction - response > protocol, and LMAP will specify how it operates over an existing > protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). > - The Report protocol and the associated data model: The definition of > how the Report is delivered from a MA to a Collector; this includes > a Data Model consistent with the Information Model plus a transport > protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). >=20 > Sorry for the length of this message. >=20 > /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 dromasca@avaya.com Thu May 23 00:39:25 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5C621F96C8 for ; Thu, 23 May 2013 00:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1rbdQWdNpgm for ; Thu, 23 May 2013 00:39:20 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 104F321F96C1 for ; Thu, 23 May 2013 00:39:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusFAEHGnVHGmAcF/2dsb2JhbABYA4JnITDCJIEJFnSCIwEBAQEDEigtCwcMAgICAQgNAwEEAQELFAkHGxcUCQgCBAENBQgah2sBnl2cBxcEjWKBBiEQBwYLgmJhA5NnihKKf4MPgWk9 X-IronPort-AV: E=Sophos;i="4.87,726,1363147200"; d="scan'208";a="12863607" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 May 2013 03:39:19 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 May 2013 03:34:03 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Thu, 23 May 2013 03:39:17 -0400 From: "Romascanu, Dan (Dan)" To: "MORTON JR., ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] charter discussion status Thread-Index: AQHOVyiWJb/q7dYgAUmTk/qX3ZjWTZkR8MeAgABq5SA= Date: Thu, 23 May 2013 07:39:16 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17531C@AZ-FFEXMB04.global.avaya.com> References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> <20130522201141.GA30745@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 07:39:26 -0000 My preference is for separate documents for the Information Model (possibly= only one), Data Models (two), and Protocols (two).=20 Dan > -----Original Message----- > From: MORTON JR., ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Wednesday, May 22, 2013 11:51 PM > To: Juergen Schoenwaelder > Cc: Benoit Claise; Romascanu, Dan (Dan); lmap@ietf.org > Subject: RE: [lmap] charter discussion status >=20 > Thanks for your suggestion of revised text, Juergen. >=20 > When you go to the trouble of clarifying sections by re-writing them, > there's no limit on message length, and excerpted text doesn't count. ;- > ) >=20 > Taking it a step further, does your proposal to emphasize the > Information Model obviate the separate memos on the Control and > Reporting Data Models, and thus we should remove them from the > milestones, or is the non-abstract expression of each Data Model useful > to keep separate from the Protocol memos? >=20 > Al >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, May 22, 2013 4:12 PM > ... > > > > The phrase 'fields and their arrangement (the order they appear in and > > any hierarchy)' should be something like 'fields and their > > relationships'. It would be wrong to prescribe certain hierarchical > > nestings since protocols may have different constraints there. > > > > The first item is an information model. This is fine. The second and > > third items are data models. I would argue that the details what > > should be cover should be moved to the information model - the data > > models simply have to consistent with the information model. The > > fourth and fifth items talk about protocols and once again data > > models. This means confusing overlap. > > > > To sum up, here is a significantly simplified version: > > > > - Information Model, the abstract definition of the information > carried > > from the Controller to the MA and the information carried from the > MA > > to the Collector. It includes the metric(s) to be measured and > > values for its parameters such as the Peer MA participating in the > > measurement and the desired environmental conditions (for example, > only > > conduct the measurement when there is no user traffic observed). It > > also includes the schedule (when the measurement should be run) and > how > > the results should be reported (when and to which Collector). It > > further includes the metric(s) measured and when, the actual > > result, and supporting metadata such as location. Result reports may > > be organized in batches or may be reported immediately, such as for > an > > on-demand measurement. > > - The Control protocol and the associated data model: The definition > of > > how instructions are delivered from a Controller to a MA; this > > includes a Data Model consistent with the Information Model plus a > > transport protocol. This is a simple instruction - response > > protocol, and LMAP will specify how it operates over an existing > > protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). > > - The Report protocol and the associated data model: The definition of > > how the Report is delivered from a MA to a Collector; this includes > > a Data Model consistent with the Information Model plus a transport > > protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). > > > > Sorry for the length of this message. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 From bclaise@cisco.com Thu May 23 02:22:15 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA09221F96A1 for ; Thu, 23 May 2013 02:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.425 X-Spam-Level: X-Spam-Status: No, score=-10.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bOIvOp199Fn for ; Thu, 23 May 2013 02:22:11 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 273E621F968E for ; Thu, 23 May 2013 02:22:11 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4N9M437027983; Thu, 23 May 2013 11:22:05 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4N9LVcK015679; Thu, 23 May 2013 11:21:41 +0200 (CEST) Message-ID: <519DDF9B.3000702@cisco.com> Date: Thu, 23 May 2013 11:21:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "MORTON JR., ALFRED C (AL)" References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Dan Romascanu , "lmap@ietf.org" Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 09:22:15 -0000 On 22/05/2013 17:39, MORTON JR., ALFRED C (AL) wrote: >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Tuesday, May 14, 2013 6:44 AM >> To: MORTON JR., ALFRED C (AL); Dan Romascanu; lmap@ietf.org >> Subject: Re: charter discussion status >> >> Hi Jüergen, >> >> Timely question. >> As far as I'm concerned, the couple of clarifying questions I asked on >> the mailing list are now addressed. >> Al, Dan, and I are working on the charter proposal. >> You can expect some charter proposal very soon. >> >> Regards, Benoit >> > The "first" draft charter text is appended below. > > It would be ideal if readers could hold-off on nit-level comments > and post the most significant issues first (but we won't try to achieve > consensus on significance). And you have no significant issues, please let us know. Regards, Benoit > You get points for suggesting editorial > improvements, but please send them to Dan and Al, not the list. > And last, let us suggest that commenters take the extra time necessary to > write a brief message when posting to the list. All subscribers will > appreciate your efforts. > > regards, > Dan and Al > > -=-=-=-=-=-=-=-=-=- > > Name: Large-Scale Measurement of Broadband Performance (LMAP) > > AREA: Operations and Management > > Chairs: > TBD > TBD > > OPS Area Directors: > > Benoit Claise > Joel Jaeggli > > > OPS Area Advisor: > Benoit Claise > > Mailing Lists: > General Discussion: lmap at ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/lmap > Archive: http://www.ietf.org/mail-archive/web/lmap > > > Description of Working Group > > Measuring portions of the Internet on a large scale is vital for > accurate characterizations of performance over time and geography, for > network diagnostic investigations by providers and their users, and for > collecting information to support public policy development. The > ultimate goal is to have the same measurements for a large number of > points on the Internet, conducted according to the same > characterization plan, and to have the results collected and stored in > the same form. > > Many measurement systems that exist today use proprietary, > custom-designed mechanisms to coordinate their Measurement Agents (MAs) > deployed across networks, to communicate between MAs and measurement > Controllers, and to transfer results to measurement Collectors. > Standardizing these mechanisms (Control protocol, Report protocol, > and corresponding data models) will make it possible to incorporate > interoperable measurement communications into home and enterprise > edge routers, personal computers, mobile devices and other networking > devices, whether wired or wireless. Standards will help these management > capabilities become more pervasive and facilitate measurement results > that are directly comparable. > > The Large-Scale Measurement of Broadband Performance (LMAP) working > group is chartered to determine the form of data models and > select/extend one or more protocols for the communications between the > Measurement Agents' (MAs) function and their Controller function and > Collector function. These three functions comprise the LMAP measurement > system. > > The standardized LMAP mechanisms will allow a Controller to instruct > MAs what performance metrics to measure, when to measure them, and > how/when to report the measurement results to a Collector. The primary > products of the working group are the data models that define the > measurement instructions and reports, and protocols for securely > delivering these data models to/from the MAs. Data models should be > extensible for new and additional measurements. > > A key assumption constraining the initial work is that the measurement > system is under the control of a single organization (for example, an > Internet Service Provider or a regulator). However, the components of > an LMAP measurement system can be deployed in administrative domains > that are not owned by the measuring organization. Thus, the system of > functions deployed by a single organization constitutes a single LMAP > domain which may span ownership or other administrative boundaries. > > The LMAP architecture will allow for measurements that utilize either > IPv4 or IPv6, or possibly both. Devices containing MAs may have several > interfaces using different link technologies. Multiple address families > and interfaces must be considered in the Control and Reporting > protocols. > > It is assumed that different organization's LMAP measurement domains > can overlap, and that active measurement packets appear along with > normal user traffic when crossing another organization's network. In > the initial chartering phase, there is no requirement to specify a > mechanism for coordination between the LMAP measurements in overlapping > domains (for instance a home network with MAs on the home hub, set top > box and laptop). In principle, there are no restrictions on the type of > device in which the MA function resides. > > Both active and passive measurements are in scope, although there may > be differences in their applicability to specific use cases, or in the > security measures needed according to the threats specific to each > measurement category. At a high level, LMAP systems are agnostic to the > measurements and results, and extensible to incorporate evolution in > the measurement area, but the details such as the data models must be > standardized to match the measurements. > > Inter-organization communication of results is a consideration not > addressed in the LMAP system and deferred to bi-lateral agreements. > > Many measurement aspects are already within the charter of IPPM. These > include standardized definitions of performance metrics, MA-to-MA > measurement protocols, and a registry of frequently-used metrics and > parameter settings so they can be identified in an efficient and > consistent fashion. Neither the definition of the new metrics and > methods of measurement, nor the post-processing and analysis of results > falls within the remit of LMAP. > > The case where an end user can independently perform network diagnostic > measurements (beyond their private network) is not directly in scope, > recognizing that users have many opportunities to do this today. > However, end users can obtain an MA to run measurement tasks if desired > and report their results to whomever they want, most likely the > supplier of the MA. This provides for user-initiated on-demand > measurement, which is an important component of the ISP use case. > > Another area that is out of scope is the management protocol to > bootstrap the MAs in measurement devices, although a bootstrapping > process may be described and conducted in many ways, such as > configuration during manufacture or with a local USB interface. > Discovering the service parameters on the MAs or sharing the service > parameters between MAs are out of the scope of the LMAP charter. > However, if the service parameters are available to the MAs, they could > be combined with the measurement results in the Report Protocol. > > Service parameters can be used to decide which measurements to run, or > to interpret the results (for example, when assigning the correct > product categorization). These parameters are already gathered and > stored by existing operations systems. Deciding the set of measurements > to run is a business decision and is out of scope. > > Exhaustive protection against all possibilities of gaming the > measurements - where gaming is defined as intentionally (and perhaps > maliciously) inserting inaccuracy into the overall system or > measurement process - is beyond the scope of work. Some protections are > lawyer problems, not engineering problems. However, the working group > may include protections that do not add significant complexity, as > determined by working group consensus. > > The LMAP working group will coordinate with other standards bodies > working in this area (e.g., BBF, IEEE 802.16, ETSI), and other IETF > working groups in the areas of data models, protocols, multiple > interface management, and measurement of performance metrics. > > LMAP will consider re-use of existing protocols and data model > languages in its efforts to produce the following work items: > > - The LMAP Framework - provides common terminology and justifies the > simplifying constraints > - The LMAP Use Cases - provides the motivating use cases as a basis for > the work > - Information Models, the abstract definition of the measurement tasks > and the Report; the semantics of the fields and their arrangement (the > order they appear in and any hierarchy). > - A Data model that defines how the Controller tells an MA to execute a > measurement instruction. It includes the metric(s) to be measured and > values for its parameters such as the Peer MA participating in the > measurement and the desired environmental conditions (for example, only > conduct the measurement when there is no user traffic observed). It > also includes the schedule (when the measurement should be run) and how > the results should be reported (when and to which Collector). > - A Data model that defines the report that the MA sends to the > Collector. It includes the metric(s) measured and when, the actual > result, and supporting metadata such as location. Results reports may > be organized in batches or may be reported immediately, such as for an > on-demand measurement. > - The Control protocol: The definition of how instructions are > delivered from a Controller to a MA; a Data Model plus a transport > protocol. This is a simple instruction - response protocol, and LMAP > will specify how it operates over an existing protocol (to be selected, > perhaps REST-style HTTP(s) or Netconf). > - The Report protocol: The definition of how the Report is delivered > from a MA to a Collector; a Data Model plus a transport protocol (to be > selected, possibly IPFIX). > > Goals and Milestones > > Sep 2013: Initial WG I-D for the LMAP Framework including terminology > Sep 2013: Initial WG I-D for the LMAP Use cases > Dec 2013: Submit the LMAP Framework I-D to the IESG for consideration > as Informational RFC > Dec 2013: Submit I-D on the LMAP Use cases to the IESG for > consideration as Informational RFC > Jan 2014: Initial WG I-D for LMAP Information models > Jan 2014: Initial WG I-D for the Control protocol > Jan 2014: Initial WG I-D for the Report protocol > Apr 2014: Initial WG I-D for a Data model for LMAP control information > Apr 2014: Initial WG I-D for a Data model for LMAP report information > July 2014: Submit the LMAP Information models I-D to the IESG for > consideration as Standards track RFC > July 2014: Submit the Control protocol I-D to the IESG for > consideration as Standards track RFC > July 2014: Submit Report protocol I-D to the IESG for consideration as > Standards track RFC > Dec 2014: Submit the Data model for LMAP control I-D to the IESG for > consideration as Standards track RFC > Dec 2014: Submit the Data model for LMAP report I-D to the IESG for > consideration as Standards track RFC > > > > From bclaise@cisco.com Thu May 23 02:22:58 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B707521F969D for ; Thu, 23 May 2013 02:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.429 X-Spam-Level: X-Spam-Status: No, score=-10.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzSZINIZ25dt for ; Thu, 23 May 2013 02:22:54 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id F114D21F9673 for ; Thu, 23 May 2013 02:22:53 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4N9MiTb028072; Thu, 23 May 2013 11:22:44 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4N9M3EU016409; Thu, 23 May 2013 11:22:19 +0200 (CEST) Message-ID: <519DDFBB.2000802@cisco.com> Date: Thu, 23 May 2013 11:22:03 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> <20130522201141.GA30745@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA17531C@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA17531C@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Juergen Schoenwaelder , "MORTON JR., ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 09:22:58 -0000 On 23/05/2013 09:39, Romascanu, Dan (Dan) wrote: > My preference is for separate documents for the Information Model (possibly only one), Data Models (two), and Protocols (two). That makes sense to me. Regards, Benoit > Dan > > >> -----Original Message----- >> From: MORTON JR., ALFRED C (AL) [mailto:acmorton@att.com] >> Sent: Wednesday, May 22, 2013 11:51 PM >> To: Juergen Schoenwaelder >> Cc: Benoit Claise; Romascanu, Dan (Dan); lmap@ietf.org >> Subject: RE: [lmap] charter discussion status >> >> Thanks for your suggestion of revised text, Juergen. >> >> When you go to the trouble of clarifying sections by re-writing them, >> there's no limit on message length, and excerpted text doesn't count. ;- >> ) >> >> Taking it a step further, does your proposal to emphasize the >> Information Model obviate the separate memos on the Control and >> Reporting Data Models, and thus we should remove them from the >> milestones, or is the non-abstract expression of each Data Model useful >> to keep separate from the Protocol memos? >> >> Al >> >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Wednesday, May 22, 2013 4:12 PM >> ... >>> The phrase 'fields and their arrangement (the order they appear in and >>> any hierarchy)' should be something like 'fields and their >>> relationships'. It would be wrong to prescribe certain hierarchical >>> nestings since protocols may have different constraints there. >>> >>> The first item is an information model. This is fine. The second and >>> third items are data models. I would argue that the details what >>> should be cover should be moved to the information model - the data >>> models simply have to consistent with the information model. The >>> fourth and fifth items talk about protocols and once again data >>> models. This means confusing overlap. >>> >>> To sum up, here is a significantly simplified version: >>> >>> - Information Model, the abstract definition of the information >> carried >>> from the Controller to the MA and the information carried from the >> MA >>> to the Collector. It includes the metric(s) to be measured and >>> values for its parameters such as the Peer MA participating in the >>> measurement and the desired environmental conditions (for example, >> only >>> conduct the measurement when there is no user traffic observed). It >>> also includes the schedule (when the measurement should be run) and >> how >>> the results should be reported (when and to which Collector). It >>> further includes the metric(s) measured and when, the actual >>> result, and supporting metadata such as location. Result reports may >>> be organized in batches or may be reported immediately, such as for >> an >>> on-demand measurement. >>> - The Control protocol and the associated data model: The definition >> of >>> how instructions are delivered from a Controller to a MA; this >>> includes a Data Model consistent with the Information Model plus a >>> transport protocol. This is a simple instruction - response >>> protocol, and LMAP will specify how it operates over an existing >>> protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). >>> - The Report protocol and the associated data model: The definition of >>> how the Report is delivered from a MA to a Collector; this includes >>> a Data Model consistent with the Information Model plus a transport >>> protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). >>> >>> Sorry for the length of this message. >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 > From j.schoenwaelder@jacobs-university.de Thu May 23 02:32:39 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEA321F9690 for ; Thu, 23 May 2013 02:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.168 X-Spam-Level: X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LxAMnSXR7fT for ; Thu, 23 May 2013 02:32:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D9A4B21F9619 for ; Thu, 23 May 2013 02:32:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A78820BF4; Thu, 23 May 2013 11:32:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 95Q-BinWVZuG; Thu, 23 May 2013 11:32:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9118D20BF3; Thu, 23 May 2013 11:32:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 436C2266ECBE; Thu, 23 May 2013 11:32:29 +0200 (CEST) Date: Thu, 23 May 2013 11:32:28 +0200 From: Juergen Schoenwaelder To: "MORTON JR., ALFRED C (AL)" Message-ID: <20130523093227.GA32573@elstar.local> Mail-Followup-To: "MORTON JR., ALFRED C (AL)" , Benoit Claise , Dan Romascanu , "lmap@ietf.org" References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> <20130522201141.GA30745@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Benoit Claise , Dan Romascanu , "lmap@ietf.org" Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 09:32:39 -0000 On Wed, May 22, 2013 at 04:50:41PM -0400, MORTON JR., ALFRED C (AL) wrote: > Taking it a step further, does your proposal to emphasize the > Information Model obviate the separate memos on the Control and > Reporting Data Models, and thus we should remove them from the > milestones, or is the non-abstract expression of each Data Model > useful to keep separate from the Protocol memos? For some possible protocols, the data model is clearly separated from the protocol. For other possible protocols, the data model is part of the resource model you work with, e.g. you define what the REST resources are and how they react to GET/PUT/POST/DELETE and what they expects as input and return as output. In this case, separating the data model description from the protocol makes things likely difficult to read and understand. (See the ALTO specification as an example of a REST approach where things are bundled together.) Hence I decided to mention protocol and data model under one item, assuming that the WG will take a decision later when the protocols are selected whether these will end up in different documents or not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu May 23 02:55:10 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367B821F9601 for ; Thu, 23 May 2013 02:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbOBFNOlXhiY for ; Thu, 23 May 2013 02:55:05 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 166E421F8A00 for ; Thu, 23 May 2013 02:55:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwFADTmnVHGmAcF/2dsb2JhbABXA4JnITDCK4EKFnSCIwEBAQEDAQEBDyg0CwwCAgIBCA0BAgEEAQEBChQJBxsMCxQJCAIEDgUIGodrAQueL5wHFwSOaCEQBwYLgmJhA515in+DD4Im X-IronPort-AV: E=Sophos;i="4.87,727,1363147200"; d="scan'208";a="12876450" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 May 2013 05:55:03 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 May 2013 05:49:48 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Thu, 23 May 2013 05:55:02 -0400 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "MORTON JR., ALFRED C (AL)" Thread-Topic: [lmap] charter discussion status Thread-Index: AQHOV5hwJb/q7dYgAUmTk/qX3ZjWTZkSh9ew Date: Thu, 23 May 2013 09:55:02 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA175738@AZ-FFEXMB04.global.avaya.com> References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> <20130522201141.GA30745@elstar.local> <20130523093227.GA32573@elstar.local> In-Reply-To: <20130523093227.GA32573@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 09:55:10 -0000 Good point.=20 Dan > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: Thursday, May 23, 2013 12:32 PM > To: MORTON JR., ALFRED C (AL) > Cc: Benoit Claise; Romascanu, Dan (Dan); lmap@ietf.org > Subject: Re: [lmap] charter discussion status >=20 > On Wed, May 22, 2013 at 04:50:41PM -0400, MORTON JR., ALFRED C (AL) > wrote: >=20 > > Taking it a step further, does your proposal to emphasize the > > Information Model obviate the separate memos on the Control and > > Reporting Data Models, and thus we should remove them from the > > milestones, or is the non-abstract expression of each Data Model > > useful to keep separate from the Protocol memos? >=20 > For some possible protocols, the data model is clearly separated from > the protocol. For other possible protocols, the data model is part of > the resource model you work with, e.g. you define what the REST > resources are and how they react to GET/PUT/POST/DELETE and what they > expects as input and return as output. In this case, separating the data > model description from the protocol makes things likely difficult to > read and understand. (See the ALTO specification as an example of a > REST approach where things are bundled together.) >=20 > Hence I decided to mention protocol and data model under one item, > assuming that the WG will take a decision later when the protocols are > selected whether these will end up in different documents or not. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From Michael.K.Bugenhagen@centurylink.com Thu May 23 05:56:49 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6D21F9017 for ; Thu, 23 May 2013 05:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAqRtlG7XGW8 for ; Thu, 23 May 2013 05:56:44 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id EA72421F8FED for ; Thu, 23 May 2013 05:56:43 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r4NCucoL002837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 07:56:39 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 78A101E0067; Thu, 23 May 2013 06:56:33 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 56A411E005E; Thu, 23 May 2013 06:56:33 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r4NCuWoW027543; Thu, 23 May 2013 06:56:32 -0600 (MDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r4NCuWTx027537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 May 2013 06:56:32 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.02.0318.001; Thu, 23 May 2013 07:56:32 -0500 From: "Bugenhagen, Michael K" To: "'Benoit Claise'" , "MORTON JR., ALFRED C (AL)" Thread-Topic: [lmap] charter discussion status Thread-Index: Ac5QkBlfK3L5NZQjQTCN3cU5EfJ1YQGcBVfgADAo1YAAA1ZTQA== Date: Thu, 23 May 2013 12:56:31 +0000 Message-ID: References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> <519DDF9B.3000702@cisco.com> In-Reply-To: <519DDF9B.3000702@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.16.192] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Dan Romascanu , "lmap@ietf.org" Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 12:56:49 -0000 Benoit - I see two specific clauses that I feel need to be added, and of course I'= ll make contributions to such areas in the future provided the group adds t= hese to the charter.... 1) Access Service Attribute Validation - ( I would put this under the sect= ion where it describes a measurement domain putting MA's in ISP domain) LMAP should define a standard interface, and protocol to obtain near-real = time access service provisioning attributes to ensure the test results are = being conducted and compared to actual ISP terms of service. 2) Testing Control group mechanisms ( I recommend changing the "gaming" p= aragraph to reflect this) LMAP may recommend creation of "control group tests" which are specificall= y designed to validate and investigate results, thereby lowering the risk o= f gaming the test results by special treatment of test traffic. Thanks, Mike =20 =09 =09 -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Ben= oit Claise Sent: Thursday, May 23, 2013 4:22 AM To: MORTON JR., ALFRED C (AL) Cc: Dan Romascanu; lmap@ietf.org Subject: Re: [lmap] charter discussion status On 22/05/2013 17:39, MORTON JR., ALFRED C (AL) wrote: >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Tuesday, May 14, 2013 6:44 AM >> To: MORTON JR., ALFRED C (AL); Dan Romascanu; lmap@ietf.org >> Subject: Re: charter discussion status >> >> Hi J=FCergen, >> >> Timely question. >> As far as I'm concerned, the couple of clarifying questions I asked=20 >> on the mailing list are now addressed. >> Al, Dan, and I are working on the charter proposal. >> You can expect some charter proposal very soon. >> >> Regards, Benoit >> > The "first" draft charter text is appended below. > > It would be ideal if readers could hold-off on nit-level comments and=20 > post the most significant issues first (but we won't try to achieve=20 > consensus on significance). And you have no significant issues, please let us know. Regards, Benoit > You get points for suggesting editorial improvements, but please send=20 > them to Dan and Al, not the list. > And last, let us suggest that commenters take the extra time necessary=20 > to write a brief message when posting to the list. All subscribers=20 > will appreciate your efforts. > > regards, > Dan and Al > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > > Name: Large-Scale Measurement of Broadband Performance (LMAP) > > AREA: Operations and Management > > Chairs: > TBD > TBD > > OPS Area Directors: > =20 > Benoit Claise > Joel Jaeggli > > > OPS Area Advisor: > Benoit Claise > > Mailing Lists: > General Discussion: lmap at ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/lmap > Archive: http://www.ietf.org/mail-archive/web/lmap > > > Description of Working Group > > Measuring portions of the Internet on a large scale is vital for=20 > accurate characterizations of performance over time and geography, for=20 > network diagnostic investigations by providers and their users, and=20 > for collecting information to support public policy development. The=20 > ultimate goal is to have the same measurements for a large number of=20 > points on the Internet, conducted according to the same=20 > characterization plan, and to have the results collected and stored in=20 > the same form. > > Many measurement systems that exist today use proprietary,=20 > custom-designed mechanisms to coordinate their Measurement Agents=20 > (MAs) deployed across networks, to communicate between MAs and=20 > measurement Controllers, and to transfer results to measurement Collector= s. > Standardizing these mechanisms (Control protocol, Report protocol, and=20 > corresponding data models) will make it possible to incorporate=20 > interoperable measurement communications into home and enterprise edge=20 > routers, personal computers, mobile devices and other networking=20 > devices, whether wired or wireless. Standards will help these=20 > management capabilities become more pervasive and facilitate=20 > measurement results that are directly comparable. > > The Large-Scale Measurement of Broadband Performance (LMAP) working=20 > group is chartered to determine the form of data models and=20 > select/extend one or more protocols for the communications between the=20 > Measurement Agents' (MAs) function and their Controller function and=20 > Collector function. These three functions comprise the LMAP=20 > measurement system. > > The standardized LMAP mechanisms will allow a Controller to instruct=20 > MAs what performance metrics to measure, when to measure them, and=20 > how/when to report the measurement results to a Collector. The=20 > primary products of the working group are the data models that define=20 > the measurement instructions and reports, and protocols for securely=20 > delivering these data models to/from the MAs. Data models should be=20 > extensible for new and additional measurements. > > A key assumption constraining the initial work is that the measurement=20 > system is under the control of a single organization (for example, an=20 > Internet Service Provider or a regulator). However, the components of=20 > an LMAP measurement system can be deployed in administrative domains=20 > that are not owned by the measuring organization. Thus, the system of=20 > functions deployed by a single organization constitutes a single LMAP=20 > domain which may span ownership or other administrative boundaries. > > The LMAP architecture will allow for measurements that utilize either > IPv4 or IPv6, or possibly both. Devices containing MAs may have=20 > several interfaces using different link technologies. Multiple address=20 > families and interfaces must be considered in the Control and=20 > Reporting protocols. > > It is assumed that different organization's LMAP measurement domains=20 > can overlap, and that active measurement packets appear along with=20 > normal user traffic when crossing another organization's network. In=20 > the initial chartering phase, there is no requirement to specify a=20 > mechanism for coordination between the LMAP measurements in=20 > overlapping domains (for instance a home network with MAs on the home=20 > hub, set top box and laptop). In principle, there are no restrictions=20 > on the type of device in which the MA function resides. > > Both active and passive measurements are in scope, although there may=20 > be differences in their applicability to specific use cases, or in the=20 > security measures needed according to the threats specific to each=20 > measurement category. At a high level, LMAP systems are agnostic to=20 > the measurements and results, and extensible to incorporate evolution=20 > in the measurement area, but the details such as the data models must=20 > be standardized to match the measurements. > > Inter-organization communication of results is a consideration not=20 > addressed in the LMAP system and deferred to bi-lateral agreements. > > Many measurement aspects are already within the charter of IPPM. These=20 > include standardized definitions of performance metrics, MA-to-MA=20 > measurement protocols, and a registry of frequently-used metrics and=20 > parameter settings so they can be identified in an efficient and=20 > consistent fashion. Neither the definition of the new metrics and=20 > methods of measurement, nor the post-processing and analysis of=20 > results falls within the remit of LMAP. > > The case where an end user can independently perform network=20 > diagnostic measurements (beyond their private network) is not directly=20 > in scope, recognizing that users have many opportunities to do this today= . > However, end users can obtain an MA to run measurement tasks if=20 > desired and report their results to whomever they want, most likely=20 > the supplier of the MA. This provides for user-initiated on-demand=20 > measurement, which is an important component of the ISP use case. > > Another area that is out of scope is the management protocol to=20 > bootstrap the MAs in measurement devices, although a bootstrapping=20 > process may be described and conducted in many ways, such as=20 > configuration during manufacture or with a local USB interface. > Discovering the service parameters on the MAs or sharing the service=20 > parameters between MAs are out of the scope of the LMAP charter. > However, if the service parameters are available to the MAs, they=20 > could be combined with the measurement results in the Report Protocol. > > Service parameters can be used to decide which measurements to run, or=20 > to interpret the results (for example, when assigning the correct=20 > product categorization). These parameters are already gathered and=20 > stored by existing operations systems. Deciding the set of=20 > measurements to run is a business decision and is out of scope. > =20 > Exhaustive protection against all possibilities of gaming the=20 > measurements - where gaming is defined as intentionally (and perhaps > maliciously) inserting inaccuracy into the overall system or=20 > measurement process - is beyond the scope of work. Some protections=20 > are lawyer problems, not engineering problems. However, the working=20 > group may include protections that do not add significant complexity,=20 > as determined by working group consensus. > > The LMAP working group will coordinate with other standards bodies=20 > working in this area (e.g., BBF, IEEE 802.16, ETSI), and other IETF=20 > working groups in the areas of data models, protocols, multiple=20 > interface management, and measurement of performance metrics. > > LMAP will consider re-use of existing protocols and data model=20 > languages in its efforts to produce the following work items: > > - The LMAP Framework - provides common terminology and justifies the=20 > simplifying constraints > - The LMAP Use Cases - provides the motivating use cases as a basis=20 > for the work > - Information Models, the abstract definition of the measurement tasks=20 > and the Report; the semantics of the fields and their arrangement (the=20 > order they appear in and any hierarchy). > - A Data model that defines how the Controller tells an MA to execute=20 > a measurement instruction. It includes the metric(s) to be measured=20 > and values for its parameters such as the Peer MA participating in the=20 > measurement and the desired environmental conditions (for example,=20 > only conduct the measurement when there is no user traffic observed).=20 > It also includes the schedule (when the measurement should be run) and=20 > how the results should be reported (when and to which Collector). > - A Data model that defines the report that the MA sends to the=20 > Collector. It includes the metric(s) measured and when, the actual=20 > result, and supporting metadata such as location. Results reports may=20 > be organized in batches or may be reported immediately, such as for an=20 > on-demand measurement. > - The Control protocol: The definition of how instructions are=20 > delivered from a Controller to a MA; a Data Model plus a transport=20 > protocol. This is a simple instruction - response protocol, and LMAP=20 > will specify how it operates over an existing protocol (to be=20 > selected, perhaps REST-style HTTP(s) or Netconf). > - The Report protocol: The definition of how the Report is delivered=20 > from a MA to a Collector; a Data Model plus a transport protocol (to=20 > be selected, possibly IPFIX). > > Goals and Milestones > > Sep 2013: Initial WG I-D for the LMAP Framework including terminology=20 > Sep 2013: Initial WG I-D for the LMAP Use cases Dec 2013: Submit the=20 > LMAP Framework I-D to the IESG for consideration as Informational RFC=20 > Dec 2013: Submit I-D on the LMAP Use cases to the IESG for=20 > consideration as Informational RFC Jan 2014: Initial WG I-D for LMAP=20 > Information models Jan 2014: Initial WG I-D for the Control protocol=20 > Jan 2014: Initial WG I-D for the Report protocol Apr 2014: Initial WG=20 > I-D for a Data model for LMAP control information Apr 2014: Initial WG=20 > I-D for a Data model for LMAP report information July 2014: Submit the=20 > LMAP Information models I-D to the IESG for consideration as Standards=20 > track RFC July 2014: Submit the Control protocol I-D to the IESG for=20 > consideration as Standards track RFC July 2014: Submit Report protocol=20 > I-D to the IESG for consideration as Standards track RFC Dec 2014:=20 > Submit the Data model for LMAP control I-D to the IESG for=20 > consideration as Standards track RFC Dec 2014: Submit the Data model=20 > for LMAP report I-D to the IESG for consideration as Standards track=20 > RFC > > > > _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From yaojk@cnnic.cn Sun May 26 19:43:35 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF16721F940B for ; Sun, 26 May 2013 19:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.294 X-Spam-Level: X-Spam-Status: No, score=-99.294 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nhxjk5+AfNnp for ; Sun, 26 May 2013 19:43:31 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 8945421F9401 for ; Sun, 26 May 2013 19:43:28 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO healthyao-think) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 27 May 2013 10:43:22 +0800 Date: Mon, 27 May 2013 10:43:21 +0800 From: "Jiankang Yao" To: "Juergen Schoenwaelder" , =?gb2312?B?TU9SVE9OIEpSLiwgQUxGUkVEIEMgKEFMKQ==?= References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> <20130522201141.GA30745@elstar.local> , <20130523093227.GA32573@elstar.local> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2013052710422132865421@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart701715436106_=----" Cc: Benoit Claise , Dan Romascanu , "lmap@ietf.org" Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: yaojk List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 02:43:35 -0000 This is a multi-part message in MIME format. ------=_001_NextPart701715436106_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQp3aGV0aGVyIHRoZSBkYXRhIG1vZGVscyBhbmQgcHJvdG9jb2xzIGFyZSBzZXBhcmF0ZWQgb3Ig bm90LCBpdCBpcyBzdWdnZXN0ZWQgdGhhdCANCkZyYW1ld29yayBkb2N1ZW1udCBzaG91bGQgY2xl YXIgYWJvdXQgaXQgYW5kIHNheSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGRhdGEgbW9k ZWxzIGRvY3VtZW50cyBhbmQgcHJvdG9jb2wgZG9jdW1lbnRzIGlmIHRoZXkgYXJlIHNlcGFyYXRl ZC4NCg0KDQoNCg0KSmlhbmthbmcgWWFvDQoNCkZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0K RGF0ZTogMjAxMy0wNS0yMyAxNzozMg0KVG86IE1PUlRPTiBKUi4sIEFMRlJFRCBDIChBTCkNCkND OiBCZW5vaXQgQ2xhaXNlOyBEYW4gUm9tYXNjYW51OyBsbWFwQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW2xtYXBdIGNoYXJ0ZXIgZGlzY3Vzc2lvbiBzdGF0dXMNCk9uIFdlZCwgTWF5IDIyLCAyMDEz IGF0IDA0OjUwOjQxUE0gLTA0MDAsIE1PUlRPTiBKUi4sIEFMRlJFRCBDIChBTCkgd3JvdGU6DQoN Cj4gVGFraW5nIGl0IGEgc3RlcCBmdXJ0aGVyLCBkb2VzIHlvdXIgcHJvcG9zYWwgdG8gZW1waGFz aXplIHRoZQ0KPiBJbmZvcm1hdGlvbiBNb2RlbCBvYnZpYXRlIHRoZSBzZXBhcmF0ZSBtZW1vcyBv biB0aGUgQ29udHJvbCBhbmQNCj4gUmVwb3J0aW5nIERhdGEgTW9kZWxzLCBhbmQgdGh1cyB3ZSBz aG91bGQgcmVtb3ZlIHRoZW0gZnJvbSB0aGUNCj4gbWlsZXN0b25lcywgb3IgaXMgdGhlIG5vbi1h YnN0cmFjdCBleHByZXNzaW9uIG9mIGVhY2ggRGF0YSBNb2RlbA0KPiB1c2VmdWwgdG8ga2VlcCBz ZXBhcmF0ZSBmcm9tIHRoZSBQcm90b2NvbCBtZW1vcz8NCg0KRm9yIHNvbWUgcG9zc2libGUgcHJv dG9jb2xzLCB0aGUgZGF0YSBtb2RlbCBpcyBjbGVhcmx5IHNlcGFyYXRlZCBmcm9tDQp0aGUgcHJv dG9jb2wuIEZvciBvdGhlciBwb3NzaWJsZSBwcm90b2NvbHMsIHRoZSBkYXRhIG1vZGVsIGlzIHBh cnQgb2YNCnRoZSByZXNvdXJjZSBtb2RlbCB5b3Ugd29yayB3aXRoLCBlLmcuIHlvdSBkZWZpbmUg d2hhdCB0aGUgUkVTVA0KcmVzb3VyY2VzIGFyZSBhbmQgaG93IHRoZXkgcmVhY3QgdG8gR0VUL1BV VC9QT1NUL0RFTEVURSBhbmQgd2hhdCB0aGV5DQpleHBlY3RzIGFzIGlucHV0IGFuZCByZXR1cm4g YXMgb3V0cHV0LiBJbiB0aGlzIGNhc2UsIHNlcGFyYXRpbmcgdGhlDQpkYXRhIG1vZGVsIGRlc2Ny aXB0aW9uIGZyb20gdGhlIHByb3RvY29sIG1ha2VzIHRoaW5ncyBsaWtlbHkgZGlmZmljdWx0DQp0 byByZWFkIGFuZCB1bmRlcnN0YW5kLiAgKFNlZSB0aGUgQUxUTyBzcGVjaWZpY2F0aW9uIGFzIGFu IGV4YW1wbGUgb2YNCmEgUkVTVCBhcHByb2FjaCB3aGVyZSB0aGluZ3MgYXJlIGJ1bmRsZWQgdG9n ZXRoZXIuKQ0KDQpIZW5jZSBJIGRlY2lkZWQgdG8gbWVudGlvbiBwcm90b2NvbCBhbmQgZGF0YSBt b2RlbCB1bmRlciBvbmUgaXRlbSwNCmFzc3VtaW5nIHRoYXQgdGhlIFdHIHdpbGwgdGFrZSBhIGRl Y2lzaW9uIGxhdGVyIHdoZW4gdGhlIHByb3RvY29scyBhcmUNCnNlbGVjdGVkIHdoZXRoZXIgdGhl c2Ugd2lsbCBlbmQgdXAgaW4gZGlmZmVyZW50IGRvY3VtZW50cyBvciBub3QuDQoNCi9qcw0KDQot LSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJl bWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEs IDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8 aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbG1hcCBtYWlsaW5nIGxpc3QNCmxtYXBAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcA== ------=_001_NextPart701715436106_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
whether the data models and protocols are separated or not, it is sug= gested=20 that
Framework docuemnt should clear about it and say the relationship bet= ween=20 the data models documents and protocol documents if they are separated.
 
Jiankang Yao
 
From: Juergen=20 Schoenwaelder
Date: 2013-05-23 17:32
CC: Benoit Claise; Dan Romascanu; lmap@ietf.org
Subject: Re: [lmap] charter discussion status
=
On Wed, May 22, 2013 at 04:50:41PM = ;-0400, MORTON JR., ALFRED C (AL) wrote:
 
> Taking it a step further, does&nbs= p;your proposal to emphasize the
> Information Model obviate the separate&= nbsp;memos on the Control and
> Reporting Data Models, and thus we=  should remove them from the
> milestones, or is the non-abstract = ;expression of each Data Model
> useful to keep separate from the&n= bsp;Protocol memos?
 
For some possible protocols, the data m= odel is clearly separated from
the protocol. For other possible protocols,&= nbsp;the data model is part of
the resource model you work with, e.g.&= nbsp;you define what the REST
resources are and how they react to&nbs= p;GET/PUT/POST/DELETE and what they
expects as input and return as output.&= nbsp;In this case, separating the
data model description from the protocol&nbs= p;makes things likely difficult
to read and understand.  (See the = ALTO specification as an example of
a REST approach where things are bundle= d together.)
 
Hence I decided to mention protocol and=  data model under one item,
assuming that the WG will take a d= ecision later when the protocols are
selected whether these will end up in&n= bsp;different documents or not.
 
/js
 
-- 
Juergen Schoenwaelder       &= nbsp;   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587    &n= bsp;    Campus Ring 1, 28759 Breme= n, Germany
Fax:   +49 421 200 3103  &nbs= p;      <http://www.jacobs-university.de/= >
_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap
------=_001_NextPart701715436106_=------ From philip.eardley@bt.com Wed May 29 03:57:13 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8B821F8EF7 for ; Wed, 29 May 2013 03:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqeQRFKxOnFF for ; Wed, 29 May 2013 03:57:08 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id C7E6721F8D90 for ; Wed, 29 May 2013 03:57:07 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 29 May 2013 11:57:06 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.200]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Wed, 29 May 2013 11:57:06 +0100 From: To: , , , Date: Wed, 29 May 2013 11:57:06 +0100 Thread-Topic: charter discussion status Thread-Index: Ac5QkBlfK3L5NZQjQTCN3cU5EfJ1YQGcBVfgAVX0O0A= Message-ID: <9510D26531EF184D9017DF24659BB87F34B481075C@EMV65-UKRD.domain1.systemhost.net> References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 10:57:13 -0000 Thanks for the work on this, it looks good to me.=20 I like Juergen's changes and agree with deciding later whether each data mo= del & protocol is bundled together. Also agree with doing a single Informat= ion Model document, because the report is likely to echo several parts of t= he Instruction. > Another area that is out of scope is the management protocol to > bootstrap the MAs in measurement devices, although a bootstrapping > process may be described and conducted in many ways, such as > configuration during manufacture or with a local USB interface. At one point we discussed detailing the bootstrap process but not the boots= trap protocol. from the text, I'm not sure whether we'll work on the bootst= rap process. To the extent it could be covered in the framework doc, I'm ok= to include it (but don't object if we don't) > Goals and Milestones ... > Dec 2013: Submit the LMAP Framework I-D to the IESG for consideration as = Informational RFC I think an important milestone is for us to reach consensus on which protoc= ol(s) we will re-use or extend for the Control and Report protocol (I assum= e we won't define a new protocol) I think the framework doc would be a good place to record this consensus an= d that the timescale is realistic (ie the WG makes a decision in the autumn= ) ... > Jan 2014: Initial WG I-D for LMAP Information models=20 I think this is very pessimistic (for your info, some of us are planning to= submit an individual i-d for Berlin) Juergen's changes mean the other milestones need adjusting, I suggest:- Jan 2014: Initial WG I-D for the Control protocol and the associated data m= odel=20 Apr 2014: Initial WG I-D for the Report protocol and the associated data mo= del July 2014: Submit WG I-D for the Control protocol and the associated data m= odel to the IESG for consideration as Standards track RFC July 2014: Submit WG I-D for the Report protocol and the associated data mo= del to the IESG for consideration as Standards track RFC I suggested staggering the initial I-D deadlines. Seems more natural to do = Control first. We should finish them together, as there may be dependencies= . Thanks phil=20 From philip.eardley@bt.com Wed May 29 04:04:15 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D8F21F8F7A for ; Wed, 29 May 2013 04:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpgPcIPvx-To for ; Wed, 29 May 2013 04:04:11 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAB021F8F2C for ; Wed, 29 May 2013 04:04:05 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 29 May 2013 12:04:04 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.200]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 29 May 2013 12:04:04 +0100 From: To: , , Date: Wed, 29 May 2013 12:04:03 +0100 Thread-Topic: [lmap] charter discussion status Thread-Index: Ac5QkBlfK3L5NZQjQTCN3cU5EfJ1YQGcBVfgADAo1YAAA1ZTQAEjRrmQ Message-ID: <9510D26531EF184D9017DF24659BB87F34B4810770@EMV65-UKRD.domain1.systemhost.net> References: <20130514084140.GA12748@elstar.local> <51921584.8040505@cisco.com> <519DDF9B.3000702@cisco.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dromasca@avaya.com, lmap@ietf.org Subject: Re: [lmap] charter discussion status X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 11:04:15 -0000 Mike I think both of the topics are interesting On 1, I think this is something the framework doc could consider (at a high= level) but I don't favour including it in the first phase of lmap work - t= hink it's better to concentrate on the Controller-MA and MA-Collector inter= faces. =20 On 2, this isn't a topic I know about, do you have references on ways this = can be done? would like to be educated. is it known how to do this or is it= an area where research is needed?=20 Formally, I guess it would fit better in IPPM, as it is a test. Best wishes phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Bugenhagen, Michael K > Sent: 23 May 2013 13:57 > To: 'Benoit Claise'; MORTON JR., ALFRED C (AL) > Cc: Dan Romascanu; lmap@ietf.org > Subject: Re: [lmap] charter discussion status >=20 > Benoit - >=20 > I see two specific clauses that I feel need to be added, and of > course I'll make contributions to such areas in the future provided the > group adds these to the charter.... >=20 >=20 >=20 >=20 > 1) Access Service Attribute Validation - ( I would put this under the > section where it describes a measurement domain putting MA's in ISP > domain) >=20 > LMAP should define a standard interface, and protocol to obtain > near-real time access service provisioning attributes to ensure the > test results are being conducted and compared to actual ISP terms of > service. >=20 >=20 >=20 >=20 > 2) Testing Control group mechanisms ( I recommend changing the > "gaming" paragraph to reflect this) >=20 > LMAP may recommend creation of "control group tests" which are > specifically designed to validate and investigate results, thereby > lowering the risk of gaming the test results by special treatment of > test traffic. >=20 >=20 >=20 >=20 > Thanks, > Mike >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Benoit Claise > Sent: Thursday, May 23, 2013 4:22 AM > To: MORTON JR., ALFRED C (AL) > Cc: Dan Romascanu; lmap@ietf.org > Subject: Re: [lmap] charter discussion status >=20 > On 22/05/2013 17:39, MORTON JR., ALFRED C (AL) wrote: > >> -----Original Message----- > >> From: Benoit Claise [mailto:bclaise@cisco.com] > >> Sent: Tuesday, May 14, 2013 6:44 AM > >> To: MORTON JR., ALFRED C (AL); Dan Romascanu; lmap@ietf.org > >> Subject: Re: charter discussion status > >> > >> Hi J=FCergen, > >> > >> Timely question. > >> As far as I'm concerned, the couple of clarifying questions I asked > >> on the mailing list are now addressed. > >> Al, Dan, and I are working on the charter proposal. > >> You can expect some charter proposal very soon. > >> > >> Regards, Benoit > >> > > The "first" draft charter text is appended below. > > > > It would be ideal if readers could hold-off on nit-level comments and > > post the most significant issues first (but we won't try to achieve > > consensus on significance). > And you have no significant issues, please let us know. >=20 > Regards, Benoit > > You get points for suggesting editorial improvements, but please send > > them to Dan and Al, not the list. > > And last, let us suggest that commenters take the extra time > necessary > > to write a brief message when posting to the list. All subscribers > > will appreciate your efforts. > > > > regards, > > Dan and Al > > > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > > > > Name: Large-Scale Measurement of Broadband Performance (LMAP) > > > > AREA: Operations and Management > > > > Chairs: > > TBD > > TBD > > > > OPS Area Directors: > > > > Benoit Claise > > Joel Jaeggli > > > > > > OPS Area Advisor: > > Benoit Claise > > > > Mailing Lists: > > General Discussion: lmap at ietf.org > > To Subscribe: http://www.ietf.org/mailman/listinfo/lmap > > Archive: http://www.ietf.org/mail-archive/web/lmap > > > > > > Description of Working Group > > > > Measuring portions of the Internet on a large scale is vital for > > accurate characterizations of performance over time and geography, > for > > network diagnostic investigations by providers and their users, and > > for collecting information to support public policy development. The > > ultimate goal is to have the same measurements for a large number of > > points on the Internet, conducted according to the same > > characterization plan, and to have the results collected and stored > in > > the same form. > > > > Many measurement systems that exist today use proprietary, > > custom-designed mechanisms to coordinate their Measurement Agents > > (MAs) deployed across networks, to communicate between MAs and > > measurement Controllers, and to transfer results to measurement > Collectors. > > Standardizing these mechanisms (Control protocol, Report protocol, > and > > corresponding data models) will make it possible to incorporate > > interoperable measurement communications into home and enterprise > edge > > routers, personal computers, mobile devices and other networking > > devices, whether wired or wireless. Standards will help these > > management capabilities become more pervasive and facilitate > > measurement results that are directly comparable. > > > > The Large-Scale Measurement of Broadband Performance (LMAP) working > > group is chartered to determine the form of data models and > > select/extend one or more protocols for the communications between > the > > Measurement Agents' (MAs) function and their Controller function and > > Collector function. These three functions comprise the LMAP > > measurement system. > > > > The standardized LMAP mechanisms will allow a Controller to instruct > > MAs what performance metrics to measure, when to measure them, and > > how/when to report the measurement results to a Collector. The > > primary products of the working group are the data models that define > > the measurement instructions and reports, and protocols for securely > > delivering these data models to/from the MAs. Data models should be > > extensible for new and additional measurements. > > > > A key assumption constraining the initial work is that the > measurement > > system is under the control of a single organization (for example, an > > Internet Service Provider or a regulator). However, the components of > > an LMAP measurement system can be deployed in administrative domains > > that are not owned by the measuring organization. Thus, the system of > > functions deployed by a single organization constitutes a single LMAP > > domain which may span ownership or other administrative boundaries. > > > > The LMAP architecture will allow for measurements that utilize either > > IPv4 or IPv6, or possibly both. Devices containing MAs may have > > several interfaces using different link technologies. Multiple > address > > families and interfaces must be considered in the Control and > > Reporting protocols. > > > > It is assumed that different organization's LMAP measurement domains > > can overlap, and that active measurement packets appear along with > > normal user traffic when crossing another organization's network. In > > the initial chartering phase, there is no requirement to specify a > > mechanism for coordination between the LMAP measurements in > > overlapping domains (for instance a home network with MAs on the home > > hub, set top box and laptop). In principle, there are no restrictions > > on the type of device in which the MA function resides. > > > > Both active and passive measurements are in scope, although there may > > be differences in their applicability to specific use cases, or in > the > > security measures needed according to the threats specific to each > > measurement category. At a high level, LMAP systems are agnostic to > > the measurements and results, and extensible to incorporate evolution > > in the measurement area, but the details such as the data models must > > be standardized to match the measurements. > > > > Inter-organization communication of results is a consideration not > > addressed in the LMAP system and deferred to bi-lateral agreements. > > > > Many measurement aspects are already within the charter of IPPM. > These > > include standardized definitions of performance metrics, MA-to-MA > > measurement protocols, and a registry of frequently-used metrics and > > parameter settings so they can be identified in an efficient and > > consistent fashion. Neither the definition of the new metrics and > > methods of measurement, nor the post-processing and analysis of > > results falls within the remit of LMAP. > > > > The case where an end user can independently perform network > > diagnostic measurements (beyond their private network) is not > directly > > in scope, recognizing that users have many opportunities to do this > today. > > However, end users can obtain an MA to run measurement tasks if > > desired and report their results to whomever they want, most likely > > the supplier of the MA. This provides for user-initiated on-demand > > measurement, which is an important component of the ISP use case. > > > > Another area that is out of scope is the management protocol to > > bootstrap the MAs in measurement devices, although a bootstrapping > > process may be described and conducted in many ways, such as > > configuration during manufacture or with a local USB interface. > > Discovering the service parameters on the MAs or sharing the service > > parameters between MAs are out of the scope of the LMAP charter. > > However, if the service parameters are available to the MAs, they > > could be combined with the measurement results in the Report > Protocol. > > > > Service parameters can be used to decide which measurements to run, > or > > to interpret the results (for example, when assigning the correct > > product categorization). These parameters are already gathered and > > stored by existing operations systems. Deciding the set of > > measurements to run is a business decision and is out of scope. > > > > Exhaustive protection against all possibilities of gaming the > > measurements - where gaming is defined as intentionally (and perhaps > > maliciously) inserting inaccuracy into the overall system or > > measurement process - is beyond the scope of work. Some protections > > are lawyer problems, not engineering problems. However, the working > > group may include protections that do not add significant complexity, > > as determined by working group consensus. > > > > The LMAP working group will coordinate with other standards bodies > > working in this area (e.g., BBF, IEEE 802.16, ETSI), and other IETF > > working groups in the areas of data models, protocols, multiple > > interface management, and measurement of performance metrics. > > > > LMAP will consider re-use of existing protocols and data model > > languages in its efforts to produce the following work items: > > > > - The LMAP Framework - provides common terminology and justifies the > > simplifying constraints > > - The LMAP Use Cases - provides the motivating use cases as a basis > > for the work > > - Information Models, the abstract definition of the measurement > tasks > > and the Report; the semantics of the fields and their arrangement > (the > > order they appear in and any hierarchy). > > - A Data model that defines how the Controller tells an MA to execute > > a measurement instruction. It includes the metric(s) to be measured > > and values for its parameters such as the Peer MA participating in > the > > measurement and the desired environmental conditions (for example, > > only conduct the measurement when there is no user traffic observed). > > It also includes the schedule (when the measurement should be run) > and > > how the results should be reported (when and to which Collector). > > - A Data model that defines the report that the MA sends to the > > Collector. It includes the metric(s) measured and when, the actual > > result, and supporting metadata such as location. Results reports may > > be organized in batches or may be reported immediately, such as for > an > > on-demand measurement. > > - The Control protocol: The definition of how instructions are > > delivered from a Controller to a MA; a Data Model plus a transport > > protocol. This is a simple instruction - response protocol, and LMAP > > will specify how it operates over an existing protocol (to be > > selected, perhaps REST-style HTTP(s) or Netconf). > > - The Report protocol: The definition of how the Report is delivered > > from a MA to a Collector; a Data Model plus a transport protocol (to > > be selected, possibly IPFIX). > > > > Goals and Milestones > > > > Sep 2013: Initial WG I-D for the LMAP Framework including terminology > > Sep 2013: Initial WG I-D for the LMAP Use cases Dec 2013: Submit the > > LMAP Framework I-D to the IESG for consideration as Informational RFC > > Dec 2013: Submit I-D on the LMAP Use cases to the IESG for > > consideration as Informational RFC Jan 2014: Initial WG I-D for LMAP > > Information models Jan 2014: Initial WG I-D for the Control protocol > > Jan 2014: Initial WG I-D for the Report protocol Apr 2014: Initial WG > > I-D for a Data model for LMAP control information Apr 2014: Initial > WG > > I-D for a Data model for LMAP report information July 2014: Submit > the > > LMAP Information models I-D to the IESG for consideration as > Standards > > track RFC July 2014: Submit the Control protocol I-D to the IESG for > > consideration as Standards track RFC July 2014: Submit Report > protocol > > I-D to the IESG for consideration as Standards track RFC Dec 2014: > > Submit the Data model for LMAP control I-D to the IESG for > > consideration as Standards track RFC Dec 2014: Submit the Data model > > for LMAP report I-D to the IESG for consideration as Standards track > > RFC > > > > > > > > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From dromasca@avaya.com Wed May 29 05:34:56 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3670521F918C for ; Wed, 29 May 2013 05:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP4QmR6VqLIN for ; Wed, 29 May 2013 05:34:51 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3272121F90D2 for ; Wed, 29 May 2013 05:34:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAH/ZlHGmAcF/2dsb2JhbABQgmUhNsFIgQcWdIIhAQEDAQEBDygtBx0BFQUQAhI3CxcPAQQKEQEZh3IBC5wRhCudI4w5gSuBAYMYYQOYI4UGimiDC4FzNQ X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="13310568" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 May 2013 08:34:49 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 May 2013 08:29:13 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Wed, 29 May 2013 08:34:48 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5caOfRrX+eILrVQJu06CxfDKZpag== Date: Wed, 29 May 2013 12:34:48 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 12:34:56 -0000 Hi,=20 Please see below another try at the lmap wg charter. I have included the ed= its discussed until now on the list which we seem to have reached agreement= . I have also aligned the milestones of the Control and Report protocols an= d data models and mentioned the option of issuing these as one or separate = documents for each (to be decided later by the WG).=20 Other comments or clarifications?=20 Is this text good enough for IESG review?=20 Regards, Dan ------------------------------ Name: Large-Scale Measurement of Broadband Performance (LMAP) AREA: Operations and Management Chairs: TBD TBD OPS Area Directors: =20 Benoit Claise Joel Jaeggli OPS Area Advisor: Benoit Claise Mailing Lists: General Discussion: lmap at ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/lmap Archive: http://www.ietf.org/mail-archive/web/lmap Description of Working Group Measuring portions of the Internet on a large scale is vital for=20 accurate characterizations of performance over time and geography, for=20 network diagnostic investigations by providers and their users, and for=20 collecting information to support public policy development. The=20 ultimate goal is to have the same measurements for a large number of=20 points on the Internet, conducted according to the same=20 characterization plan, and to have the results collected and stored in=20 the same form.=20 Many measurement systems that exist today use proprietary,=20 custom-designed mechanisms to coordinate their Measurement Agents (MAs)=20 deployed across networks, to communicate between MAs and measurement=20 Controllers, and to transfer results to measurement Collectors.=20 Standardizing these mechanisms (Control protocol, Report protocol,=20 and corresponding data models) will make it possible to incorporate=20 interoperable measurement communications into home and enterprise=20 edge routers, personal computers, mobile devices and other networking=20 devices, whether wired or wireless. Standards will help these management=20 capabilities become more pervasive and facilitate measurement results=20 that are directly comparable. The Large-Scale Measurement of Broadband Performance (LMAP) working=20 group is chartered to determine the form of data models and=20 select/extend one or more protocols for the communications between the=20 Measurement Agents' (MAs) function and their Controller function and=20 Collector function. These three functions comprise the LMAP measurement=20 system. The standardized LMAP mechanisms will allow a Controller to instruct=20 MAs what performance metrics to measure, when to measure them, =20 how/when to report the measurement results to a Collector, and then for=20 the MA to report the results to the Collector. The primary=20 products of the working group are the data models that define the=20 measurement instructions and reports, and protocols for securely=20 delivering these data models to/from the MAs. Data models should be=20 extensible for new and additional measurements. A key assumption constraining the initial work is that the measurement=20 system is under the control of a single organization (for example, an=20 Internet Service Provider or a regulator). However, the components of=20 an LMAP measurement system can be deployed in administrative domains=20 that are not owned by the measuring organization. Thus, the system of=20 functions deployed by a single organization constitutes a single LMAP=20 domain which may span ownership or other administrative boundaries.=20 The LMAP architecture will allow for measurements that utilize either=20 IPv4 or IPv6, or possibly both. Devices containing MAs may have several=20 interfaces using different link technologies. Multiple address families=20 and interfaces must be considered in the Control and Report=20 protocols. It is assumed that different organization's LMAP measurement domains=20 can overlap, and that active measurement packets appear along with=20 normal user traffic when crossing another organization's network. In=20 the initial chartering phase, there is no requirement to specify a=20 mechanism for coordination between the LMAP measurements in overlapping=20 domains (for instance a home network with MAs on the home hub, set top=20 box and laptop). In principle, there are no restrictions on the type of=20 device in which the MA function resides.=20 Both active and passive measurements are in scope, although there may=20 be differences in their applicability to specific use cases, or in the=20 security measures needed according to the threats specific to each=20 measurement category. At a high level, LMAP systems are agnostic to the=20 measurements and results, and extensible to incorporate evolution in=20 the measurement area, but the details such as the data models must be=20 standardized to match the measurements. Inter-organization communication of results is not addressed in the=20 LMAP system and is deferred to bi-lateral agreements. Many measurement aspects are already within the charter of IPPM. These=20 include standardized definitions of performance metrics, MA-to-MA=20 measurement protocols, and a registry of frequently-used metrics and=20 parameter settings so they can be identified in an efficient and=20 consistent fashion. Neither the definition of the new metrics and=20 methods of measurement, nor the post-processing and analysis of results=20 falls within the remit of LMAP.=20 The case where an end user can independently perform network diagnostic=20 measurements (beyond their private network) is not directly in scope,=20 recognizing that users have many opportunities to do this today.=20 However, end users can obtain an MA to run measurement tasks if desired=20 and report their results to whomever they want, most likely the=20 supplier of the MA. This provides for user-initiated on-demand=20 measurement, which is an important component of the ISP use case. Another area that is out of scope is the management protocol to=20 bootstrap the MAs in measurement devices, although a bootstrapping=20 process may be described and conducted in many ways, such as=20 configuration during manufacture or with a local USB interface.=20 Discovering the service parameters on the MAs or sharing the service=20 parameters between MAs are out of the scope of the LMAP charter.=20 However, if the service parameters are available to the MAs, they could=20 be combined with the measurement results in the Report Protocol. Service parameters, such as product category, can be useful to decide=20 which measurements to run and how to interpret the results. These=20 parameters are already gathered and stored by existing operations=20 systems. Deciding the set of measurements to run is a business decision=20 and is out of scope. =20 Exhaustive protection against all possibilities of gaming the=20 measurements - where gaming is defined as intentionally (and perhaps=20 maliciously) inserting inaccuracy into the overall system or=20 measurement process - is beyond the scope of work. Some protections are=20 lawyer problems, not engineering problems. However, the working group=20 may include protections that do not add significant complexity, as=20 determined by working group consensus. The LMAP working group will coordinate with other standards bodies=20 working in this area (e.g., BBF, IEEE 802.16, ETSI), and other IETF=20 working groups in the areas of data models, protocols, multiple=20 interface management, and measurement of performance metrics. LMAP will consider re-use of existing protocols and data model=20 languages in its efforts to produce the following work items: - The LMAP Framework - provides common terminology and justifies the=20 simplifying constraints=20 - The LMAP Use Cases - provides the motivating use cases as a basis for=20 the work=20 - Information Model, the abstract definition of the information carried from the Controller to the MA and the information carried from the MA to the Collector. It includes - the metric(s) to be measured and values for its parameters such as the Peer MA participating in the measurement and the desired environmental conditions (for example, only conduct the measurement when there is no user traffic observed)=20 - the schedule: when the measurement should be run and how the results should be reported (when and to which Collector) - the report: the metric(s) measured and when, the actual result, and supporting metadata such as location. Result reports may=20 be organized in batches or may be reported immediately, such as for an on-demand measurement. - The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus a transport protocol. This is a simple instruction - response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). - The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). The WG will decide later whether protocols and data models (for Control,=20 respectively Report) will be defined in one or separated documents.=20 =20 Goals and Milestones Sep 2013: Initial WG I-D for the LMAP Framework including terminology=20 Sep 2013: Initial WG I-D for the LMAP Use cases Dec 2013: Submit the LMAP Framework I-D to the IESG for consideration=20 as Informational RFC Dec 2013: Submit I-D on the LMAP Use cases to the IESG for=20 consideration as Informational RFC Jan 2014: Initial WG I-D for LMAP Information models Apr 2014: Initial WG I-D for the Control protocol=20 Apr 2014: Initial WG I-D for the Report protocol=20 Apr 2014: Initial WG I-D for a Data model for LMAP control information Apr 2014: Initial WG I-D for a Data model for LMAP report information July 2014: Submit the LMAP Information models I-D to the IESG for=20 consideration as Standards track RFC Dec 2014: Submit the Control protocol I-D to the IESG for=20 consideration as Standards track RFC Dec 2014: Submit the Report protocol I-D to the IESG for consideration as=20 Standards track RFC Dec 2014: Submit the Data model for LMAP control I-D to the IESG for=20 consideration as Standards track RFC Dec 2014: Submit the Data model for LMAP report I-D to the IESG for=20 consideration as Standards track RFC From philip.eardley@bt.com Wed May 29 08:38:53 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290E021F9385 for ; Wed, 29 May 2013 08:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD5UcdIrkFg0 for ; Wed, 29 May 2013 08:38:49 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id C955321F9402 for ; Wed, 29 May 2013 08:38:48 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 29 May 2013 16:38:47 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.200]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 29 May 2013 16:38:47 +0100 From: To: , Date: Wed, 29 May 2013 16:38:46 +0100 Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5caOfRrX+eILrVQJu06CxfDKZpagAGZvqg Message-ID: <9510D26531EF184D9017DF24659BB87F34B4810966@EMV65-UKRD.domain1.systemhost.net> References: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 15:38:53 -0000 No more comments, definitely seems good enough for iesg review Thanks! phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: 29 May 2013 13:35 > To: lmap@ietf.org > Subject: [lmap] lmap charter - draft 2 >=20 > Hi, >=20 > Please see below another try at the lmap wg charter. I have included > the edits discussed until now on the list which we seem to have reached > agreement. I have also aligned the milestones of the Control and Report > protocols and data models and mentioned the option of issuing these as > one or separate documents for each (to be decided later by the WG). >=20 > Other comments or clarifications? >=20 > Is this text good enough for IESG review? >=20 > Regards, >=20 > Dan >=20 >=20 > ------------------------------ >=20 > Name: Large-Scale Measurement of Broadband Performance (LMAP) >=20 > AREA: Operations and Management >=20 > Chairs: > TBD > TBD >=20 > OPS Area Directors: >=20 > Benoit Claise > Joel Jaeggli >=20 >=20 > OPS Area Advisor: > Benoit Claise >=20 > Mailing Lists: > General Discussion: lmap at ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/lmap > Archive: http://www.ietf.org/mail-archive/web/lmap >=20 >=20 > Description of Working Group >=20 > Measuring portions of the Internet on a large scale is vital for > accurate characterizations of performance over time and geography, for > network diagnostic investigations by providers and their users, and for > collecting information to support public policy development. The > ultimate goal is to have the same measurements for a large number of > points on the Internet, conducted according to the same > characterization plan, and to have the results collected and stored in > the same form. >=20 > Many measurement systems that exist today use proprietary, custom- > designed mechanisms to coordinate their Measurement Agents (MAs) > deployed across networks, to communicate between MAs and measurement > Controllers, and to transfer results to measurement Collectors. > Standardizing these mechanisms (Control protocol, Report protocol, and > corresponding data models) will make it possible to incorporate > interoperable measurement communications into home and enterprise edge > routers, personal computers, mobile devices and other networking > devices, whether wired or wireless. Standards will help these > management capabilities become more pervasive and facilitate > measurement results that are directly comparable. >=20 > The Large-Scale Measurement of Broadband Performance (LMAP) working > group is chartered to determine the form of data models and > select/extend one or more protocols for the communications between the > Measurement Agents' (MAs) function and their Controller function and > Collector function. These three functions comprise the LMAP measurement > system. >=20 > The standardized LMAP mechanisms will allow a Controller to instruct > MAs what performance metrics to measure, when to measure them, how/when > to report the measurement results to a Collector, and then for the MA > to report the results to the Collector. The primary products of the > working group are the data models that define the measurement > instructions and reports, and protocols for securely delivering these > data models to/from the MAs. Data models should be extensible for new > and additional measurements. >=20 > A key assumption constraining the initial work is that the measurement > system is under the control of a single organization (for example, an > Internet Service Provider or a regulator). However, the components of > an LMAP measurement system can be deployed in administrative domains > that are not owned by the measuring organization. Thus, the system of > functions deployed by a single organization constitutes a single LMAP > domain which may span ownership or other administrative boundaries. >=20 > The LMAP architecture will allow for measurements that utilize either > IPv4 or IPv6, or possibly both. Devices containing MAs may have several > interfaces using different link technologies. Multiple address families > and interfaces must be considered in the Control and Report protocols. >=20 > It is assumed that different organization's LMAP measurement domains > can overlap, and that active measurement packets appear along with > normal user traffic when crossing another organization's network. In > the initial chartering phase, there is no requirement to specify a > mechanism for coordination between the LMAP measurements in overlapping > domains (for instance a home network with MAs on the home hub, set top > box and laptop). In principle, there are no restrictions on the type of > device in which the MA function resides. >=20 > Both active and passive measurements are in scope, although there may > be differences in their applicability to specific use cases, or in the > security measures needed according to the threats specific to each > measurement category. At a high level, LMAP systems are agnostic to the > measurements and results, and extensible to incorporate evolution in > the measurement area, but the details such as the data models must be > standardized to match the measurements. >=20 > Inter-organization communication of results is not addressed in the > LMAP system and is deferred to bi-lateral agreements. >=20 > Many measurement aspects are already within the charter of IPPM. These > include standardized definitions of performance metrics, MA-to-MA > measurement protocols, and a registry of frequently-used metrics and > parameter settings so they can be identified in an efficient and > consistent fashion. Neither the definition of the new metrics and > methods of measurement, nor the post-processing and analysis of results > falls within the remit of LMAP. >=20 > The case where an end user can independently perform network diagnostic > measurements (beyond their private network) is not directly in scope, > recognizing that users have many opportunities to do this today. > However, end users can obtain an MA to run measurement tasks if desired > and report their results to whomever they want, most likely the > supplier of the MA. This provides for user-initiated on-demand > measurement, which is an important component of the ISP use case. >=20 > Another area that is out of scope is the management protocol to > bootstrap the MAs in measurement devices, although a bootstrapping > process may be described and conducted in many ways, such as > configuration during manufacture or with a local USB interface. > Discovering the service parameters on the MAs or sharing the service > parameters between MAs are out of the scope of the LMAP charter. > However, if the service parameters are available to the MAs, they could > be combined with the measurement results in the Report Protocol. >=20 > Service parameters, such as product category, can be useful to decide > which measurements to run and how to interpret the results. These > parameters are already gathered and stored by existing operations > systems. Deciding the set of measurements to run is a business decision > and is out of scope. >=20 > Exhaustive protection against all possibilities of gaming the > measurements - where gaming is defined as intentionally (and perhaps > maliciously) inserting inaccuracy into the overall system or > measurement process - is beyond the scope of work. Some protections are > lawyer problems, not engineering problems. However, the working group > may include protections that do not add significant complexity, as > determined by working group consensus. >=20 > The LMAP working group will coordinate with other standards bodies > working in this area (e.g., BBF, IEEE 802.16, ETSI), and other IETF > working groups in the areas of data models, protocols, multiple > interface management, and measurement of performance metrics. >=20 > LMAP will consider re-use of existing protocols and data model > languages in its efforts to produce the following work items: >=20 > - The LMAP Framework - provides common terminology and justifies the > simplifying constraints > - The LMAP Use Cases - provides the motivating use cases as a basis for > the work > - Information Model, the abstract definition of the information carried > from the Controller to the MA and the information carried from the MA > to the Collector. It includes > - the metric(s) to be measured and > values for its parameters such as the Peer MA participating in the > measurement and the desired environmental conditions (for example, > only > conduct the measurement when there is no user traffic observed) > - the schedule: when the measurement should be run and how > the results should be reported (when and to which Collector) > - the report: the metric(s) measured and when, the actual > result, and supporting metadata such as location. Result reports may > be organized in batches or may be reported immediately, such as for > an > on-demand measurement. > - The Control protocol and the associated data model: The definition of > how instructions are delivered from a Controller to a MA; this > includes a Data Model consistent with the Information Model plus a > transport protocol. This is a simple instruction - response > protocol, and LMAP will specify how it operates over an existing > protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). > - The Report protocol and the associated data model: The definition of > how the Report is delivered from a MA to a Collector; this includes > a Data Model consistent with the Information Model plus a transport > protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). >=20 > The WG will decide later whether protocols and data models (for > Control, respectively Report) will be defined in one or separated > documents. >=20 > Goals and Milestones >=20 > Sep 2013: Initial WG I-D for the LMAP Framework including terminology > Sep 2013: Initial WG I-D for the LMAP Use cases Dec 2013: Submit the > LMAP Framework I-D to the IESG for consideration as Informational RFC > Dec 2013: Submit I-D on the LMAP Use cases to the IESG for > consideration as Informational RFC Jan 2014: Initial WG I-D for LMAP > Information models Apr 2014: Initial WG I-D for the Control protocol > Apr 2014: Initial WG I-D for the Report protocol Apr 2014: Initial WG > I-D for a Data model for LMAP control information Apr 2014: Initial WG > I-D for a Data model for LMAP report information July 2014: Submit the > LMAP Information models I-D to the IESG for consideration as Standards > track RFC Dec 2014: Submit the Control protocol I-D to the IESG for > consideration as Standards track RFC Dec 2014: Submit the Report > protocol I-D to the IESG for consideration as Standards track RFC Dec > 2014: Submit the Data model for LMAP control I-D to the IESG for > consideration as Standards track RFC Dec 2014: Submit the Data model > for LMAP report I-D to the IESG for consideration as Standards track > RFC >=20 >=20 >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Wed May 29 12:31:05 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96A021F8EAD for ; Wed, 29 May 2013 12:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brS4Zl-1ksRa for ; Wed, 29 May 2013 12:30:51 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7B21F97AE for ; Wed, 29 May 2013 12:30:50 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id a6756a15.533a7940.382727.00-559.1084511.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 29 May 2013 19:30:50 +0000 (UTC) X-MXL-Hash: 51a6576a64e2b926-b19702be8425217dd6cf29c74b64d53d8330572e Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 96756a15.0.382700.00-261.1084413.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 29 May 2013 19:30:49 +0000 (UTC) X-MXL-Hash: 51a657692250517b-6937f6c7d6c9a5094cdccd5a53ac7f46466c7672 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4TJUmIb012396; Wed, 29 May 2013 15:30:49 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4TJUbvV012216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 15:30:41 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 29 May 2013 19:30:22 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Wed, 29 May 2013 15:30:24 -0400 From: "STARK, BARBARA H" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5caOfRrX+eILrVQJu06CxfDKZpagAKmuQQ Date: Wed, 29 May 2013 19:30:24 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CAA0A@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@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.199.78.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=S61uNvQP c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=XF2aQeIDtRMA:10 a=NuZxi4Up2mcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=jwgqLBMEQXgA:10 a=lqorK_kfVf90i6_VbscA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=nGwWNpTlJ5g663AV:21 a=qLNIHMTp7n35r0MI:21] Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 19:31:05 -0000 Sorry I didn't manage to write my comments last week. I kept running out of= time, because I didn't want to just throw my comments over the wall withou= t suggesting language. I have a big concern about language in the charter that suggests lmap will = standardize The Protocols to Be Used, and suggestions that this would be pa= rticularly useful. I think that attempting to pick The Protocols to Be Used= would result in a futile religious war. It's futile because we've agreed t= hat the MA, Controller and Collector are all under a single administrative = domain -- so whoever owns that domain will select the protocols they will u= se. I would prefer if the charter were to identify existing IETF-defined pr= otocols that *can* be used, describe any nuances to their use for lmap purp= oses, define extensions as necessary, and define any data models that would= be needed to use them for lmap purposes. All without any hint or suggestio= n to imply they *must* be used. And before doing that, requirements for wha= t constitutes a good protocol would also be useful. Such requirements can n= ot only be used to identify the gaps in existing IETF protocols, but would = also be useful to any "domain administrators" in developing criteria for wh= at they need out of a protocol that is used in systems they procure (that w= asn't invented here). In addition, I've had people tell me privately that they think my idea of d= efining a standard DNS-SD Service Instance for an xml page on a router that= can provide whatever info that router may want to share about WAN link uti= lization, its LAN link metrics, service attributes it may know, etc. would = be a good idea. But for some reason, they don't support the idea publicly o= n this list. So I'm going to try one more time to put this in scope. If no-= one speaks up, I'll consider the idea dead here, and will pursue it in BBF.= I think it will be less useful as a BBF-only defined DNS-SD Service Instan= ce, because I think it would be also useful if off-the-shelf consumer CE ro= uters (e.g., D-Link, Belkin) could be encouraged to use this to provide sta= ndard-format information about WAN link utilization and LAN link metrics to= home networked devices. But so be it. > Standardizing these mechanisms (Control protocol, Report protocol, and > corresponding data models) will make it possible to incorporate > interoperable measurement communications into home and enterprise edge > routers, personal computers, mobile devices and other networking devices, > whether wired or wireless. Standards will help these management > capabilities become more pervasive and facilitate measurement results tha= t > are directly comparable. Recommend re-wording to make this focus on the need for requirements of pro= tocols and not on a specific set of standardized protocols: Standardizing the requirements for mechanisms (Control protocol, Report pro= tocol, and corresponding data models) will ensure that all protocols that a= re used for these purposes are capable of controlling the same set of measu= rements and reporting the measurement data in a standardized manner. This w= ill allow for consistency in protocol capabilities and behavior, without co= nstraining the deploying entity unnecessarily in protocol selection. It wil= l make it possible to incorporate interoperable measurement communications = into home and enterprise edge routers, personal computers, mobile devices a= nd other networking devices, whether wired or wireless. Standardized requir= ements will help these management capabilities become more pervasive and fa= cilitate measurement results that are directly comparable. > The Large-Scale Measurement of Broadband Performance (LMAP) working > group is chartered to determine the form of data models and select/extend > one or more protocols for the communications between the Measurement > Agents' (MAs) function and their Controller function and Collector functi= on. > These three functions comprise the LMAP measurement system. Recommend adding the protocol requirements as a deliverable, and limiting t= he scope of protocol extension to IETF-specified protocols: The Large-Scale Measurement of Broadband Performance (LMAP) working group i= s chartered to determine protocol requirements, determine the form of data = models and identify/extend one or more IETF-specified protocols for the com= munications between the Measurement Agents' (MAs) function and their Contro= ller function and Collector function. These three functions comprise the LM= AP measurement system. > The standardized LMAP mechanisms will allow a Controller to instruct MAs > what performance metrics to measure, when to measure them, how/when > to report the measurement results to a Collector, and then for the MA to > report the results to the Collector. The primary products of the working > group are the data models that define the measurement instructions and > reports, and protocols for securely delivering these data models to/from = the > MAs. Data models should be extensible for new and additional > measurements. I recommend:=20 The requirements for LMAP mechanisms will allow a Controller to instruct MA= s what performance metrics to measure, when to measure them, how/when to re= port the measurement results to a Collector, and then for the MA to report = the results to the Collector. The primary products of the working group are= the protocol requirements, the data models that define the measurement ins= tructions and reports, and identification/extension of IETF-specified proto= cols for securely delivering these data models to/from the MAs. Data models= should be extensible for new and additional measurements. > The case where an end user can independently perform network diagnostic > measurements (beyond their private network) is not directly in scope, > recognizing that users have many opportunities to do this today. > However, end users can obtain an MA to run measurement tasks if desired > and report their results to whomever they want, most likely the supplier = of > the MA. This provides for user-initiated on-demand measurement, which is > an important component of the ISP use case. I would prefer to delete the phrase ", most likely the supplier of the MA".= I actually think the most likely choice here will be for the end user to r= eport the results to the end user. But I don't think this point is particul= ar worthy of discussion. =20 > Discovering the service parameters on the MAs or sharing the service > parameters between MAs are out of the scope of the LMAP charter. > However, if the service parameters are available to the MAs, they could b= e > combined with the measurement results in the Report Protocol. Recommend: Mechanisms for exchanging service parameters external to an end user's netw= ork is out of scope of the LMAP charter. However, the data model of these s= ervice attributes is in scope, where they could be combined with the measur= ement results in the Report Protocol. A mechanism that would allow a CE Rou= ter inside the end user's network to provide other devices inside the end u= ser network with information is in scope. > Service parameters, such as product category, can be useful to decide whi= ch > measurements to run and how to interpret the results. These parameters > are already gathered and stored by existing operations systems. Deciding > the set of measurements to run is a business decision and is out of scope= . The last sentence seems out of place, since I don't see how it relates to t= he first 2 sentences. I think the last sentence could be added at the end o= f a different paragraph, like the one that starts "It is assumed that diffe= rent organization's LMAP measurement domains can overlap..." or the one tha= t starts "Both active and passive measurements are in scope..." > LMAP will consider re-use of existing protocols and data model languages = in > its efforts to produce the following work items: > - The LMAP Framework - provides common terminology and justifies the simp= lifying constraints > - The Control protocol and the associated data model: The definition of > how instructions are delivered from a Controller to a MA; this > includes a Data Model consistent with the Information Model plus a > transport protocol. This is a simple instruction - response > protocol, and LMAP will specify how it operates over an existing > protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). > - The Report protocol and the associated data model: The definition of > how the Report is delivered from a MA to a Collector; this includes > a Data Model consistent with the Information Model plus a transport > protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). As it relates to deliverables, I think the protocol requirements should be = included in the framework, and don't need to be a separate deliverable. BTW, the term "transport protocol" kind of threw me in the description of t= he protocols. I was wondering if "application protocol" might be better. Recommend: - The LMAP Framework - provides common terminology and justifies the simpli= fying constraints. The framework includes requirements for the Control and = Report protocols. - The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus identifi= cation/extension of one or more IETF-specified application protocols. This is a simple instruction - response protocol, and LMAP will specify how it operates over one or more existing protocols (perhaps REST-style HTTP(s) or Netconf). - The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus identification/ex= tension of one or more IETF-specified application protocols (perhaps REST-style HTTP(s) or IPFIX). And add: - Mechanism to allow a CE Router to provide devices inside the end user net= work with various information that could be useful when analyzing measureme= nt results. > Goals and Milestones > Apr 2014: Initial WG I-D for the Control protocol=20 Recommend: Apr 2014: Initial WG I-D for the Control protocol(s) > Apr 2014: Initial WG I-D for the Report protocol=20 Recommend: Apr 2014: Initial WG I-D for Report protocol(s) Milestone around this same time for the information delivery mechanism. Barbara From dromasca@avaya.com Wed May 29 12:52:34 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA9B21F90F4 for ; Wed, 29 May 2013 12:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I8MGnkhQ00M for ; Wed, 29 May 2013 12:52:23 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id DE70421F8233 for ; Wed, 29 May 2013 12:52:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0GANlbplHGmAcF/2dsb2JhbABQCoJoITDCBIEKFnSCIwEBAQECARIoRAcEAgEIDQQEAQELFAkHMhQJCAEBBAESCBqHZQYBnTicPBeNV4ELOAaCcGEDnXyKf4MPgic X-IronPort-AV: E=Sophos;i="4.87,766,1363147200"; d="scan'208";a="11185879" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 May 2013 15:52:15 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 May 2013 15:46:35 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Wed, 29 May 2013 15:52:11 -0400 From: "Romascanu, Dan (Dan)" To: "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5caOfRrX+eILrVQJu06CxfDKZpagAKmuQQAASHtDA= Date: Wed, 29 May 2013 19:52:10 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17B060@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E611302CAA0A@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CAA0A@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 19:52:34 -0000 Hi Barbara,=20 Even if the scope of the initial phase of LMAP is designed on the assumptio= n that the measurement system is under the control of a single organization= , its components (controllers, MAs, collectors) may originate from differen= t sources (vendors of equipment and applications). How will we ensure inter= operability between these components if we do not define/select at least on= e mandatory-to-implement set of protocols and associated data models?=20 Thanks and Regards, Dan > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Wednesday, May 29, 2013 10:30 PM > To: Romascanu, Dan (Dan); lmap@ietf.org > Subject: RE: lmap charter - draft 2 >=20 > Sorry I didn't manage to write my comments last week. I kept running out > of time, because I didn't want to just throw my comments over the wall > without suggesting language. >=20 > I have a big concern about language in the charter that suggests lmap > will standardize The Protocols to Be Used, and suggestions that this > would be particularly useful. I think that attempting to pick The > Protocols to Be Used would result in a futile religious war. It's futile > because we've agreed that the MA, Controller and Collector are all under > a single administrative domain -- so whoever owns that domain will > select the protocols they will use. I would prefer if the charter were > to identify existing IETF-defined protocols that *can* be used, describe > any nuances to their use for lmap purposes, define extensions as > necessary, and define any data models that would be needed to use them > for lmap purposes. All without any hint or suggestion to imply they > *must* be used. And before doing that, requirements for what constitutes > a good protocol would also be useful. Such requirements can not only be > used to identify the gaps in existing IETF protocols, but would also be > useful to any "domain administrators" in developing criteria for what > they need out of a protocol that is used in systems they procure (that > wasn't invented here). >=20 > In addition, I've had people tell me privately that they think my idea > of defining a standard DNS-SD Service Instance for an xml page on a > router that can provide whatever info that router may want to share > about WAN link utilization, its LAN link metrics, service attributes it > may know, etc. would be a good idea. But for some reason, they don't > support the idea publicly on this list. So I'm going to try one more > time to put this in scope. If no-one speaks up, I'll consider the idea > dead here, and will pursue it in BBF. I think it will be less useful as > a BBF-only defined DNS-SD Service Instance, because I think it would be > also useful if off-the-shelf consumer CE routers (e.g., D-Link, Belkin) > could be encouraged to use this to provide standard-format information > about WAN link utilization and LAN link metrics to home networked > devices. But so be it. >=20 > > Standardizing these mechanisms (Control protocol, Report protocol, and > > corresponding data models) will make it possible to incorporate > > interoperable measurement communications into home and enterprise edge > > routers, personal computers, mobile devices and other networking > > devices, whether wired or wireless. Standards will help these > > management capabilities become more pervasive and facilitate > > measurement results that are directly comparable. >=20 > Recommend re-wording to make this focus on the need for requirements of > protocols and not on a specific set of standardized protocols: >=20 > Standardizing the requirements for mechanisms (Control protocol, Report > protocol, and corresponding data models) will ensure that all protocols > that are used for these purposes are capable of controlling the same set > of measurements and reporting the measurement data in a standardized > manner. This will allow for consistency in protocol capabilities and > behavior, without constraining the deploying entity unnecessarily in > protocol selection. It will make it possible to incorporate > interoperable measurement communications into home and enterprise edge > routers, personal computers, mobile devices and other networking > devices, whether wired or wireless. Standardized requirements will help > these management capabilities become more pervasive and facilitate > measurement results that are directly comparable. >=20 > > The Large-Scale Measurement of Broadband Performance (LMAP) working > > group is chartered to determine the form of data models and > > select/extend one or more protocols for the communications between the > > Measurement Agents' (MAs) function and their Controller function and > Collector function. > > These three functions comprise the LMAP measurement system. >=20 > Recommend adding the protocol requirements as a deliverable, and > limiting the scope of protocol extension to IETF-specified protocols: >=20 > The Large-Scale Measurement of Broadband Performance (LMAP) working > group is chartered to determine protocol requirements, determine the > form of data models and identify/extend one or more IETF-specified > protocols for the communications between the Measurement Agents' (MAs) > function and their Controller function and Collector function. These > three functions comprise the LMAP measurement system. >=20 > > The standardized LMAP mechanisms will allow a Controller to instruct > > MAs what performance metrics to measure, when to measure them, > > how/when to report the measurement results to a Collector, and then > > for the MA to report the results to the Collector. The primary > > products of the working group are the data models that define the > > measurement instructions and reports, and protocols for securely > > delivering these data models to/from the MAs. Data models should be > > extensible for new and additional measurements. >=20 > I recommend: > The requirements for LMAP mechanisms will allow a Controller to instruct > MAs what performance metrics to measure, when to measure them, how/when > to report the measurement results to a Collector, and then for the MA to > report the results to the Collector. The primary products of the working > group are the protocol requirements, the data models that define the > measurement instructions and reports, and identification/extension of > IETF-specified protocols for securely delivering these data models > to/from the MAs. Data models should be extensible for new and additional > measurements. >=20 > > The case where an end user can independently perform network > > diagnostic measurements (beyond their private network) is not directly > > in scope, recognizing that users have many opportunities to do this > today. > > However, end users can obtain an MA to run measurement tasks if > > desired and report their results to whomever they want, most likely > > the supplier of the MA. This provides for user-initiated on-demand > > measurement, which is an important component of the ISP use case. >=20 > I would prefer to delete the phrase ", most likely the supplier of the > MA". I actually think the most likely choice here will be for the end > user to report the results to the end user. But I don't think this point > is particular worthy of discussion. >=20 > > Discovering the service parameters on the MAs or sharing the service > > parameters between MAs are out of the scope of the LMAP charter. > > However, if the service parameters are available to the MAs, they > > could be combined with the measurement results in the Report Protocol. >=20 > Recommend: > Mechanisms for exchanging service parameters external to an end user's > network is out of scope of the LMAP charter. However, the data model of > these service attributes is in scope, where they could be combined with > the measurement results in the Report Protocol. A mechanism that would > allow a CE Router inside the end user's network to provide other devices > inside the end user network with information is in scope. >=20 > > Service parameters, such as product category, can be useful to decide > > which measurements to run and how to interpret the results. These > > parameters are already gathered and stored by existing operations > > systems. Deciding the set of measurements to run is a business > decision and is out of scope. >=20 > The last sentence seems out of place, since I don't see how it relates > to the first 2 sentences. I think the last sentence could be added at > the end of a different paragraph, like the one that starts "It is > assumed that different organization's LMAP measurement domains can > overlap..." or the one that starts "Both active and passive measurements > are in scope..." >=20 > > LMAP will consider re-use of existing protocols and data model > > languages in its efforts to produce the following work items: > > - The LMAP Framework - provides common terminology and justifies the > > simplifying constraints > > > - The Control protocol and the associated data model: The definition > of > > how instructions are delivered from a Controller to a MA; this > > includes a Data Model consistent with the Information Model plus a > > transport protocol. This is a simple instruction - response > > protocol, and LMAP will specify how it operates over an existing > > protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). > > - The Report protocol and the associated data model: The definition of > > how the Report is delivered from a MA to a Collector; this includes > > a Data Model consistent with the Information Model plus a transport > > protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). >=20 > As it relates to deliverables, I think the protocol requirements should > be included in the framework, and don't need to be a separate > deliverable. > BTW, the term "transport protocol" kind of threw me in the description > of the protocols. I was wondering if "application protocol" might be > better. > Recommend: > - The LMAP Framework - provides common terminology and justifies the > simplifying constraints. The framework includes requirements for the > Control and Report protocols. >=20 > - The Control protocol and the associated data model: The definition of > how instructions are delivered from a Controller to a MA; this > includes a Data Model consistent with the Information Model plus > identification/extension of one or more IETF-specified > application protocols. This is a simple instruction - response > protocol, and LMAP will specify how it operates over one or more > existing > protocols (perhaps REST-style HTTP(s) or Netconf). > - The Report protocol and the associated data model: The definition of > how the Report is delivered from a MA to a Collector; this includes > a Data Model consistent with the Information Model plus > identification/extension of one or more IETF-specified > application protocols (perhaps REST-style HTTP(s) or IPFIX). >=20 > And add: > - Mechanism to allow a CE Router to provide devices inside the end user > network with various information that could be useful when analyzing > measurement results. >=20 > > Goals and Milestones > > Apr 2014: Initial WG I-D for the Control protocol > Recommend: Apr 2014: Initial WG I-D for the Control protocol(s) >=20 > > Apr 2014: Initial WG I-D for the Report protocol > Recommend: Apr 2014: Initial WG I-D for Report protocol(s) >=20 > Milestone around this same time for the information delivery mechanism. >=20 > Barbara From Michael.K.Bugenhagen@centurylink.com Wed May 29 16:55:10 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CE321F9206 for ; Wed, 29 May 2013 16:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeVVuhgGgOS3 for ; Wed, 29 May 2013 16:55:05 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id D312621F9436 for ; Wed, 29 May 2013 16:55:00 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r4TNsvPo018446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 17:54:57 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 0CC5C1E0062; Wed, 29 May 2013 17:54:52 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id E2D4B1E0049; Wed, 29 May 2013 17:54:51 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r4TNspWO015495; Wed, 29 May 2013 17:54:51 -0600 (MDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r4TNsl8K015460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 17:54:51 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.02.0318.001; Wed, 29 May 2013 18:54:49 -0500 From: "Bugenhagen, Michael K" To: "Romascanu, Dan (Dan)" Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: AQHOXMfnTsjvrj9ZEkKCIggBQ/2LvA== Date: Wed, 29 May 2013 23:54:49 +0000 Message-ID: <4AA809CE-C6B1-4C85-80F1-0B897405DA04@centurylink.com> References: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E611302CAA0A@GAALPA1MSGUSR9L.ITServices.sbc.com>, <9904FB1B0159DA42B0B887B7FA8119CA17B060@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA17B060@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 23:55:10 -0000 Dan, =20 I believe we need to put an interface for the customer as part of the = scope, I agree which protocol that interface uses comes later - However the= question of creation of an interface should be part of the scope conversat= ion. Personally I would like to see the IETF get accolades for creating th= at, So I think it should be part of the project. Thanks Mike Sent from my iPhone On May 29, 2013, at 2:52 PM, "Romascanu, Dan (Dan)" wr= ote: > Hi Barbara,=20 >=20 > Even if the scope of the initial phase of LMAP is designed on the assumpt= ion that the measurement system is under the control of a single organizati= on, its components (controllers, MAs, collectors) may originate from differ= ent sources (vendors of equipment and applications). How will we ensure int= eroperability between these components if we do not define/select at least = one mandatory-to-implement set of protocols and associated data models?=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: STARK, BARBARA H [mailto:bs7652@att.com] >> Sent: Wednesday, May 29, 2013 10:30 PM >> To: Romascanu, Dan (Dan); lmap@ietf.org >> Subject: RE: lmap charter - draft 2 >>=20 >> Sorry I didn't manage to write my comments last week. I kept running out >> of time, because I didn't want to just throw my comments over the wall >> without suggesting language. >>=20 >> I have a big concern about language in the charter that suggests lmap >> will standardize The Protocols to Be Used, and suggestions that this >> would be particularly useful. I think that attempting to pick The >> Protocols to Be Used would result in a futile religious war. It's futile >> because we've agreed that the MA, Controller and Collector are all under >> a single administrative domain -- so whoever owns that domain will >> select the protocols they will use. I would prefer if the charter were >> to identify existing IETF-defined protocols that *can* be used, describe >> any nuances to their use for lmap purposes, define extensions as >> necessary, and define any data models that would be needed to use them >> for lmap purposes. All without any hint or suggestion to imply they >> *must* be used. And before doing that, requirements for what constitutes >> a good protocol would also be useful. Such requirements can not only be >> used to identify the gaps in existing IETF protocols, but would also be >> useful to any "domain administrators" in developing criteria for what >> they need out of a protocol that is used in systems they procure (that >> wasn't invented here). >>=20 >> In addition, I've had people tell me privately that they think my idea >> of defining a standard DNS-SD Service Instance for an xml page on a >> router that can provide whatever info that router may want to share >> about WAN link utilization, its LAN link metrics, service attributes it >> may know, etc. would be a good idea. But for some reason, they don't >> support the idea publicly on this list. So I'm going to try one more >> time to put this in scope. If no-one speaks up, I'll consider the idea >> dead here, and will pursue it in BBF. I think it will be less useful as >> a BBF-only defined DNS-SD Service Instance, because I think it would be >> also useful if off-the-shelf consumer CE routers (e.g., D-Link, Belkin) >> could be encouraged to use this to provide standard-format information >> about WAN link utilization and LAN link metrics to home networked >> devices. But so be it. >>=20 >>> Standardizing these mechanisms (Control protocol, Report protocol, and >>> corresponding data models) will make it possible to incorporate >>> interoperable measurement communications into home and enterprise edge >>> routers, personal computers, mobile devices and other networking >>> devices, whether wired or wireless. Standards will help these >>> management capabilities become more pervasive and facilitate >>> measurement results that are directly comparable. >>=20 >> Recommend re-wording to make this focus on the need for requirements of >> protocols and not on a specific set of standardized protocols: >>=20 >> Standardizing the requirements for mechanisms (Control protocol, Report >> protocol, and corresponding data models) will ensure that all protocols >> that are used for these purposes are capable of controlling the same set >> of measurements and reporting the measurement data in a standardized >> manner. This will allow for consistency in protocol capabilities and >> behavior, without constraining the deploying entity unnecessarily in >> protocol selection. It will make it possible to incorporate >> interoperable measurement communications into home and enterprise edge >> routers, personal computers, mobile devices and other networking >> devices, whether wired or wireless. Standardized requirements will help >> these management capabilities become more pervasive and facilitate >> measurement results that are directly comparable. >>=20 >>> The Large-Scale Measurement of Broadband Performance (LMAP) working >>> group is chartered to determine the form of data models and >>> select/extend one or more protocols for the communications between the >>> Measurement Agents' (MAs) function and their Controller function and >> Collector function. >>> These three functions comprise the LMAP measurement system. >>=20 >> Recommend adding the protocol requirements as a deliverable, and >> limiting the scope of protocol extension to IETF-specified protocols: >>=20 >> The Large-Scale Measurement of Broadband Performance (LMAP) working >> group is chartered to determine protocol requirements, determine the >> form of data models and identify/extend one or more IETF-specified >> protocols for the communications between the Measurement Agents' (MAs) >> function and their Controller function and Collector function. These >> three functions comprise the LMAP measurement system. >>=20 >>> The standardized LMAP mechanisms will allow a Controller to instruct >>> MAs what performance metrics to measure, when to measure them, >>> how/when to report the measurement results to a Collector, and then >>> for the MA to report the results to the Collector. The primary >>> products of the working group are the data models that define the >>> measurement instructions and reports, and protocols for securely >>> delivering these data models to/from the MAs. Data models should be >>> extensible for new and additional measurements. >>=20 >> I recommend: >> The requirements for LMAP mechanisms will allow a Controller to instruct >> MAs what performance metrics to measure, when to measure them, how/when >> to report the measurement results to a Collector, and then for the MA to >> report the results to the Collector. The primary products of the working >> group are the protocol requirements, the data models that define the >> measurement instructions and reports, and identification/extension of >> IETF-specified protocols for securely delivering these data models >> to/from the MAs. Data models should be extensible for new and additional >> measurements. >>=20 >>> The case where an end user can independently perform network >>> diagnostic measurements (beyond their private network) is not directly >>> in scope, recognizing that users have many opportunities to do this >> today. >>> However, end users can obtain an MA to run measurement tasks if >>> desired and report their results to whomever they want, most likely >>> the supplier of the MA. This provides for user-initiated on-demand >>> measurement, which is an important component of the ISP use case. >>=20 >> I would prefer to delete the phrase ", most likely the supplier of the >> MA". I actually think the most likely choice here will be for the end >> user to report the results to the end user. But I don't think this point >> is particular worthy of discussion. >>=20 >>> Discovering the service parameters on the MAs or sharing the service >>> parameters between MAs are out of the scope of the LMAP charter. >>> However, if the service parameters are available to the MAs, they >>> could be combined with the measurement results in the Report Protocol. >>=20 >> Recommend: >> Mechanisms for exchanging service parameters external to an end user's >> network is out of scope of the LMAP charter. However, the data model of >> these service attributes is in scope, where they could be combined with >> the measurement results in the Report Protocol. A mechanism that would >> allow a CE Router inside the end user's network to provide other devices >> inside the end user network with information is in scope. >>=20 >>> Service parameters, such as product category, can be useful to decide >>> which measurements to run and how to interpret the results. These >>> parameters are already gathered and stored by existing operations >>> systems. Deciding the set of measurements to run is a business >> decision and is out of scope. >>=20 >> The last sentence seems out of place, since I don't see how it relates >> to the first 2 sentences. I think the last sentence could be added at >> the end of a different paragraph, like the one that starts "It is >> assumed that different organization's LMAP measurement domains can >> overlap..." or the one that starts "Both active and passive measurements >> are in scope..." >>=20 >>> LMAP will consider re-use of existing protocols and data model >>> languages in its efforts to produce the following work items: >>> - The LMAP Framework - provides common terminology and justifies the >>> simplifying constraints >> >>> - The Control protocol and the associated data model: The definition >> of >>> how instructions are delivered from a Controller to a MA; this >>> includes a Data Model consistent with the Information Model plus a >>> transport protocol. This is a simple instruction - response >>> protocol, and LMAP will specify how it operates over an existing >>> protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). >>> - The Report protocol and the associated data model: The definition of >>> how the Report is delivered from a MA to a Collector; this includes >>> a Data Model consistent with the Information Model plus a transport >>> protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). >>=20 >> As it relates to deliverables, I think the protocol requirements should >> be included in the framework, and don't need to be a separate >> deliverable. >> BTW, the term "transport protocol" kind of threw me in the description >> of the protocols. I was wondering if "application protocol" might be >> better. >> Recommend: >> - The LMAP Framework - provides common terminology and justifies the >> simplifying constraints. The framework includes requirements for the >> Control and Report protocols. >>=20 >> - The Control protocol and the associated data model: The definition of >> how instructions are delivered from a Controller to a MA; this >> includes a Data Model consistent with the Information Model plus >> identification/extension of one or more IETF-specified >> application protocols. This is a simple instruction - response >> protocol, and LMAP will specify how it operates over one or more >> existing >> protocols (perhaps REST-style HTTP(s) or Netconf). >> - The Report protocol and the associated data model: The definition of >> how the Report is delivered from a MA to a Collector; this includes >> a Data Model consistent with the Information Model plus >> identification/extension of one or more IETF-specified >> application protocols (perhaps REST-style HTTP(s) or IPFIX). >>=20 >> And add: >> - Mechanism to allow a CE Router to provide devices inside the end user >> network with various information that could be useful when analyzing >> measurement results. >>=20 >>> Goals and Milestones >>> Apr 2014: Initial WG I-D for the Control protocol >> Recommend: Apr 2014: Initial WG I-D for the Control protocol(s) >>=20 >>> Apr 2014: Initial WG I-D for the Report protocol >> Recommend: Apr 2014: Initial WG I-D for Report protocol(s) >>=20 >> Milestone around this same time for the information delivery mechanism. >>=20 >> Barbara > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From dromasca@avaya.com Thu May 30 01:10:15 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A63C21F9811 for ; Thu, 30 May 2013 01:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhCLSkfzVO+z for ; Thu, 30 May 2013 01:10:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 690CC21F980E for ; Thu, 30 May 2013 01:09:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8GAPAIp1GHCzI1/2dsb2JhbABPCoJoITDCCnoWdIIjAQEBAQMBAQEPKDQLDAQCAQgNBAQBAQEKFAkHJwsUCQgBAQQOBQgah2sBC50mnDMTBI1XgQsxBwaCcGEDnXyKf4MPgic X-IronPort-AV: E=Sophos;i="4.87,769,1363147200"; d="scan'208";a="11243252" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 May 2013 04:09:30 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 30 May 2013 04:05:07 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Thu, 30 May 2013 10:09:26 +0200 From: "Romascanu, Dan (Dan)" To: "Bugenhagen, Michael K" Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5caOfRrX+eILrVQJu06CxfDKZpagAKmuQQAASHtDAAEP8OgAAIzQrA Date: Thu, 30 May 2013 08:09:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17B408@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E611302CAA0A@GAALPA1MSGUSR9L.ITServices.sbc.com>, <9904FB1B0159DA42B0B887B7FA8119CA17B060@AZ-FFEXMB04.global.avaya.com> <4AA809CE-C6B1-4C85-80F1-0B897405DA04@centurylink.com> In-Reply-To: <4AA809CE-C6B1-4C85-80F1-0B897405DA04@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 08:10:15 -0000 Hi Mike,=20 Can you be more specific what you mean by 'interface for the customer'? Mor= e exact: - who is the customer you have in mind?=20 - what kind of interface needs to be standardized?=20 Thanks and Regards, Dan > -----Original Message----- > From: Bugenhagen, Michael K > [mailto:Michael.K.Bugenhagen@centurylink.com] > Sent: Thursday, May 30, 2013 2:55 AM > To: Romascanu, Dan (Dan) > Cc: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] lmap charter - draft 2 >=20 > Dan, >=20 > I believe we need to put an interface for the customer as part of > the scope, I agree which protocol that interface uses comes later - > However the question of creation of an interface should be part of the > scope conversation. Personally I would like to see the IETF get > accolades for creating that, So I think it should be part of the > project. >=20 > Thanks > Mike >=20 > Sent from my iPhone >=20 > On May 29, 2013, at 2:52 PM, "Romascanu, Dan (Dan)" > wrote: >=20 > > Hi Barbara, > > > > Even if the scope of the initial phase of LMAP is designed on the > assumption that the measurement system is under the control of a single > organization, its components (controllers, MAs, collectors) may > originate from different sources (vendors of equipment and > applications). How will we ensure interoperability between these > components if we do not define/select at least one mandatory-to- > implement set of protocols and associated data models? > > > > Thanks and Regards, > > > > Dan > > > > > > > > > >> -----Original Message----- > >> From: STARK, BARBARA H [mailto:bs7652@att.com] > >> Sent: Wednesday, May 29, 2013 10:30 PM > >> To: Romascanu, Dan (Dan); lmap@ietf.org > >> Subject: RE: lmap charter - draft 2 > >> > >> Sorry I didn't manage to write my comments last week. I kept running > >> out of time, because I didn't want to just throw my comments over the > >> wall without suggesting language. > >> > >> I have a big concern about language in the charter that suggests lmap > >> will standardize The Protocols to Be Used, and suggestions that this > >> would be particularly useful. I think that attempting to pick The > >> Protocols to Be Used would result in a futile religious war. It's > >> futile because we've agreed that the MA, Controller and Collector are > >> all under a single administrative domain -- so whoever owns that > >> domain will select the protocols they will use. I would prefer if the > >> charter were to identify existing IETF-defined protocols that *can* > >> be used, describe any nuances to their use for lmap purposes, define > >> extensions as necessary, and define any data models that would be > >> needed to use them for lmap purposes. All without any hint or > >> suggestion to imply they > >> *must* be used. And before doing that, requirements for what > >> constitutes a good protocol would also be useful. Such requirements > >> can not only be used to identify the gaps in existing IETF protocols, > >> but would also be useful to any "domain administrators" in developing > >> criteria for what they need out of a protocol that is used in systems > >> they procure (that wasn't invented here). > >> > >> In addition, I've had people tell me privately that they think my > >> idea of defining a standard DNS-SD Service Instance for an xml page > >> on a router that can provide whatever info that router may want to > >> share about WAN link utilization, its LAN link metrics, service > >> attributes it may know, etc. would be a good idea. But for some > >> reason, they don't support the idea publicly on this list. So I'm > >> going to try one more time to put this in scope. If no-one speaks up, > >> I'll consider the idea dead here, and will pursue it in BBF. I think > >> it will be less useful as a BBF-only defined DNS-SD Service Instance, > >> because I think it would be also useful if off-the-shelf consumer CE > >> routers (e.g., D-Link, Belkin) could be encouraged to use this to > >> provide standard-format information about WAN link utilization and > >> LAN link metrics to home networked devices. But so be it. > >> > >>> Standardizing these mechanisms (Control protocol, Report protocol, > >>> and corresponding data models) will make it possible to incorporate > >>> interoperable measurement communications into home and enterprise > >>> edge routers, personal computers, mobile devices and other > >>> networking devices, whether wired or wireless. Standards will help > >>> these management capabilities become more pervasive and facilitate > >>> measurement results that are directly comparable. > >> > >> Recommend re-wording to make this focus on the need for requirements > >> of protocols and not on a specific set of standardized protocols: > >> > >> Standardizing the requirements for mechanisms (Control protocol, > >> Report protocol, and corresponding data models) will ensure that all > >> protocols that are used for these purposes are capable of controlling > >> the same set of measurements and reporting the measurement data in a > >> standardized manner. This will allow for consistency in protocol > >> capabilities and behavior, without constraining the deploying entity > >> unnecessarily in protocol selection. It will make it possible to > >> incorporate interoperable measurement communications into home and > >> enterprise edge routers, personal computers, mobile devices and other > >> networking devices, whether wired or wireless. Standardized > >> requirements will help these management capabilities become more > >> pervasive and facilitate measurement results that are directly > comparable. > >> > >>> The Large-Scale Measurement of Broadband Performance (LMAP) working > >>> group is chartered to determine the form of data models and > >>> select/extend one or more protocols for the communications between > >>> the Measurement Agents' (MAs) function and their Controller function > >>> and > >> Collector function. > >>> These three functions comprise the LMAP measurement system. > >> > >> Recommend adding the protocol requirements as a deliverable, and > >> limiting the scope of protocol extension to IETF-specified protocols: > >> > >> The Large-Scale Measurement of Broadband Performance (LMAP) working > >> group is chartered to determine protocol requirements, determine the > >> form of data models and identify/extend one or more IETF-specified > >> protocols for the communications between the Measurement Agents' > >> (MAs) function and their Controller function and Collector function. > >> These three functions comprise the LMAP measurement system. > >> > >>> The standardized LMAP mechanisms will allow a Controller to instruct > >>> MAs what performance metrics to measure, when to measure them, > >>> how/when to report the measurement results to a Collector, and then > >>> for the MA to report the results to the Collector. The primary > >>> products of the working group are the data models that define the > >>> measurement instructions and reports, and protocols for securely > >>> delivering these data models to/from the MAs. Data models should be > >>> extensible for new and additional measurements. > >> > >> I recommend: > >> The requirements for LMAP mechanisms will allow a Controller to > >> instruct MAs what performance metrics to measure, when to measure > >> them, how/when to report the measurement results to a Collector, and > >> then for the MA to report the results to the Collector. The primary > >> products of the working group are the protocol requirements, the data > >> models that define the measurement instructions and reports, and > >> identification/extension of IETF-specified protocols for securely > >> delivering these data models to/from the MAs. Data models should be > >> extensible for new and additional measurements. > >> > >>> The case where an end user can independently perform network > >>> diagnostic measurements (beyond their private network) is not > >>> directly in scope, recognizing that users have many opportunities to > >>> do this > >> today. > >>> However, end users can obtain an MA to run measurement tasks if > >>> desired and report their results to whomever they want, most likely > >>> the supplier of the MA. This provides for user-initiated on-demand > >>> measurement, which is an important component of the ISP use case. > >> > >> I would prefer to delete the phrase ", most likely the supplier of > >> the MA". I actually think the most likely choice here will be for the > >> end user to report the results to the end user. But I don't think > >> this point is particular worthy of discussion. > >> > >>> Discovering the service parameters on the MAs or sharing the service > >>> parameters between MAs are out of the scope of the LMAP charter. > >>> However, if the service parameters are available to the MAs, they > >>> could be combined with the measurement results in the Report > Protocol. > >> > >> Recommend: > >> Mechanisms for exchanging service parameters external to an end > >> user's network is out of scope of the LMAP charter. However, the data > >> model of these service attributes is in scope, where they could be > >> combined with the measurement results in the Report Protocol. A > >> mechanism that would allow a CE Router inside the end user's network > >> to provide other devices inside the end user network with information > is in scope. > >> > >>> Service parameters, such as product category, can be useful to > >>> decide which measurements to run and how to interpret the results. > >>> These parameters are already gathered and stored by existing > >>> operations systems. Deciding the set of measurements to run is a > >>> business > >> decision and is out of scope. > >> > >> The last sentence seems out of place, since I don't see how it > >> relates to the first 2 sentences. I think the last sentence could be > >> added at the end of a different paragraph, like the one that starts > >> "It is assumed that different organization's LMAP measurement domains > >> can overlap..." or the one that starts "Both active and passive > >> measurements are in scope..." > >> > >>> LMAP will consider re-use of existing protocols and data model > >>> languages in its efforts to produce the following work items: > >>> - The LMAP Framework - provides common terminology and justifies the > >>> simplifying constraints > >> > >>> - The Control protocol and the associated data model: The definition > >> of > >>> how instructions are delivered from a Controller to a MA; this > >>> includes a Data Model consistent with the Information Model plus a > >>> transport protocol. This is a simple instruction - response > >>> protocol, and LMAP will specify how it operates over an existing > >>> protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). > >>> - The Report protocol and the associated data model: The definition > >>> of how the Report is delivered from a MA to a Collector; this > >>> includes a Data Model consistent with the Information Model plus a > >>> transport protocol (to be selected, perhaps REST-style HTTP(s) or > IPFIX). > >> > >> As it relates to deliverables, I think the protocol requirements > >> should be included in the framework, and don't need to be a separate > >> deliverable. > >> BTW, the term "transport protocol" kind of threw me in the > >> description of the protocols. I was wondering if "application > >> protocol" might be better. > >> Recommend: > >> - The LMAP Framework - provides common terminology and justifies the > >> simplifying constraints. The framework includes requirements for the > >> Control and Report protocols. > >> > >> - The Control protocol and the associated data model: The definition > >> of how instructions are delivered from a Controller to a MA; this > >> includes a Data Model consistent with the Information Model plus > >> identification/extension of one or more IETF-specified application > >> protocols. This is a simple instruction - response protocol, and > >> LMAP will specify how it operates over one or more existing > >> protocols (perhaps REST-style HTTP(s) or Netconf). > >> - The Report protocol and the associated data model: The definition > >> of how the Report is delivered from a MA to a Collector; this > >> includes a Data Model consistent with the Information Model plus > >> identification/extension of one or more IETF-specified application > >> protocols (perhaps REST-style HTTP(s) or IPFIX). > >> > >> And add: > >> - Mechanism to allow a CE Router to provide devices inside the end > >> user network with various information that could be useful when > >> analyzing measurement results. > >> > >>> Goals and Milestones > >>> Apr 2014: Initial WG I-D for the Control protocol > >> Recommend: Apr 2014: Initial WG I-D for the Control protocol(s) > >> > >>> Apr 2014: Initial WG I-D for the Report protocol > >> Recommend: Apr 2014: Initial WG I-D for Report protocol(s) > >> > >> Milestone around this same time for the information delivery > mechanism. > >> > >> Barbara > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap From dromasca@avaya.com Thu May 30 03:27:16 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E5521F9626 for ; Thu, 30 May 2013 03:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHPVJWoTnFet for ; Thu, 30 May 2013 03:27:16 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 462B221F91B0 for ; Thu, 30 May 2013 03:27:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4FAF4op1GHCzI1/2dsb2JhbABZgmghwjt7Fm0HgiMBAQEBAxIoLh0GAQgNBAQBAQsUCTkUBwEBBQUEEwgMDodrAZh3hDacLheNUYERPoJwYQOdfIp/gw+BcTY X-IronPort-AV: E=Sophos;i="4.87,769,1363147200"; d="scan'208";a="13950339" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 30 May 2013 06:27:12 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 30 May 2013 06:22:50 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Thu, 30 May 2013 06:27:11 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Nomcom 2013-14 Volunteering - 2nd Call Thread-Index: AQHOXLAohg3/5/hJhka74OTHCGTCZZkdhgpQ Date: Thu, 30 May 2013 10:27:10 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17B872@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] FW: Nomcom 2013-14 Volunteering - 2nd Call X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 10:27:16 -0000 If you are eligible for Nomcom please consider taking part in this importan= t IETF activity.=20 Thanks and Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of Mankin, Allison Sent: Thursday, May 30, 2013 12:05 AM To: ietf-announce@ietf.org Cc: Subject: Nomcom 2013-14 Volunteering - 2nd Call Hi, everyone, Remember that I'm challenging the IETF to come up with 200 volunteers for t= he upcoming nomcom. You can volunteer just by hitting Reply to this email. What are you waiting for?? The more volunteers we get, the better chance w= e have of choosing a random yet representative cross section of the IETF po= pulation. Respond to the 200-volunteer challenge and hit Reply right now.= =20 (Well, much as I want you to do this, please look below at the posts being = filled and be sure you are willing to forgo trying for any of them this yea= r). The official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. Th= e IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, a= nd the IESG. Ten voting members for the nomcom are selected in a verifiably= random way from a pool of volunteers.=20 The details of the selection and operation of the nomcom can be found in RF= Cs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified = in RFC 3777, that means three out of the five past meetings up to the time = this email announcement goes out to start the solicitation of volunteers. T= he five meetings out of which you must have attended three are IETF 82, 83,= 84, 85, 86. If you qualify, reply to this email and volunteer. =20 The list of people and posts whose terms end with the March 2014 IETF meeti= ng, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart B= ryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be = completed in January 2014. Being a nomcom member will require some time co= mmitment - there will be interviews with candidates at meetings, regularly = scheduled conference calls to ensure progress, collection and review of req= uirements from the commitment, review of candidate questionnaires and of co= mmunity feedback. A more detailed timetable for the nomcom tasks will appe= ar soon. Please respond to this email before 11:59 pm EDT (UTC -4 hours) June 16, 20= 13. In the body include:=20 1. your Given Name as you enter it when you register for the IETF 2. your= Family Name as you enter it when you register for the IETF 3. your curren= t primary affilation (the information you enter into the Company field) 4.= any/all email addresses you've used to register for IETF meetings 5. whic= h email address you prefer 6. your phone number (for our use in confirming= you if selected). You should expect an email response from me within 3 business days stating = whether or not you are qualified (and added to the list). If you don't rec= eive this response, please re-send your email adding the tag "RESEND" to th= e subject line. Participating in the IETF nomcom is a meaningful and fun way to contribute = to the IETF. =20 Please help us meet the 200-volunteer challenge by hitting Reply to this me= ssage today. =20 Allison=20 Allison Mankin Nomcom Chair 2013-2014 =20 From bs7652@att.com Thu May 30 07:22:35 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA43921F8FF3 for ; Thu, 30 May 2013 07:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnE9Gm4C4l3h for ; Thu, 30 May 2013 07:22:22 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id AE3ED21F8C0C for ; Thu, 30 May 2013 07:22:22 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id e9067a15.2aaaf5047940.154313.00-591.435212.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 30 May 2013 14:22:22 +0000 (UTC) X-MXL-Hash: 51a7609e479a3c48-045747aa04e926d10db9fbfc4adea81ba63a1c00 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 79067a15.0.154244.00-232.434989.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 30 May 2013 14:22:16 +0000 (UTC) X-MXL-Hash: 51a76098312b5d90-a21c407f893688e0fedde46368895e053b409c8e Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UEMFiL030293; Thu, 30 May 2013 10:22:15 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UEM8YC030243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 10:22:10 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 30 May 2013 14:22:00 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.02.0342.003; Thu, 30 May 2013 10:22:02 -0400 From: "STARK, BARBARA H" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUA== Date: Thu, 30 May 2013 14:22:02 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.109.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=AaYG6QrG c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=3-4K8_7RpNEA:10 a=NuZxi4Up2mcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=jwgqLBMEQXgA:10 a=d-KtCUH4NUgaZsUfvPQA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=gQyJGLdS3vif9BI5:21 a=8DmcystUOFiU2sLr:21] Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:22:35 -0000 > Even if the scope of the initial phase of LMAP is designed on the assumpt= ion > that the measurement system is under the control of a single organization= , > its components (controllers, MAs, collectors) may originate from differen= t > sources (vendors of equipment and applications). How will we ensure > interoperability between these components if we do not define/select at > least one mandatory-to-implement set of protocols and associated data > models? Who is asking for IETF to ensure protocol-level interoperability among thes= e components? I'm definitely not. In my reading of posts of other potential procurers of = these measurement systems, I haven't seen any potential procurer ask for th= is. I could be wrong. If there are service providers who are actively wanti= ng IETF to tell them what protocols to use, I'd like for them to say so. Here is why I think this is a bad idea. IMO, the right protocols to use with any given MA depend on a number of fac= tors: - Location of the physical device (inside an end user network, or inside a= SP network -- note that not all measurements that SPs want to run are inte= nded for end user or regulatory consumption; some are intended for the SP o= nly) - Whether or not the underlying physical device is managed by the same MA = entity, and what management (bootstrap) protocol is being used for the ones= that are managed by that same entity - Whether or not the underlying physical device is dedicated to the purpose= of measurements; if measurements is not the main purpose of the physical d= evice, then the vendor of that device will have a large say in selecting pr= otocols based on what the vendor is comfortable implementing. - The nature of the actual measurement tests that are to be run - The preferences of the MA entity (who makes the purchase decisions) IMO, there are a number of cases where I would recommend TR-069 as the righ= t protocol for control and reporting. I intend to work with BBF to ensure T= R-069 can be used for this, in case my employer would like to do that. Othe= r protocols that may be "right" for various conditions include IPDR (for re= porting), OMA-DM (for control and reporting), SNMP (for control and reporti= ng), netconf (for control and reporting), IPFIX (for reporting), etc. I alr= eady know that the protocols I intend to recommend to my employer are not t= he same as what some other providers intend to use. From what I can see, al= l providers are intending to use the protocols that they consider right for= them. There is no "one size fits all" protocol answer. Trying to cram an IETF-def= ined (because I'm pretty sure IETF would never consider mandating a protoco= l that was Not Invented Here) protocol down the throats of service provider= s and vendors will create ill will and mistrust and would be futile (becaus= e IETF RFCs can easily be ignored -- SPs assign more decision-making weight= to "what's right for me" than they assign to IETF RFCs). In short, the protocols that are implemented on different devices and netwo= rk elements will be determined by their procurer and/or the supplier. If we= can get interoperable data models and consistency in the parameters used a= s inputs and outputs of test suites, then it really doesn't matter what the= control and reporting protocols are. I've seen vendors swap out or support= multiple protocols with little pain. Often, multiple protocols are impleme= nted in chip vendor SoCs. But a consistent data model across all of them --= that's big. The top thing on my IETF wish list is the data model -- both a= generic model that could be used by other orgs to create data models for t= heir protocols, and specific SNMP, netconf, and other IETF-defined protocol= data models. My recommendation to IETF wrt actually trying to mandate protocols is "don'= t go there". The bandwidth spent on the protocol religious debate will impa= ct time available for useful work, and the religious arguments will likely = cause mistrust and hard feelings that will impact people's willingness to d= o the useful work. If IETF is successful in publishing something (because p= eople like me will step back and let the religious pundits publish what the= y want -- knowing that it's easier to ignore the resulting RFC, than it is = to engage in a religious war), the resulting RFC will be ignored by any and= all who choose not to adhere to that religion. With that said, a potentially useful exercise would be to identify which pr= otocols would be better suited to different environments (based on some of = the criteria I listed above). But this could be done without attempting to = express it as a mandate. This could be presented in the form of useful guid= ance, as opposed to a religious mandate. Barbara From dromasca@avaya.com Thu May 30 07:46:20 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B634D21F84CE for ; Thu, 30 May 2013 07:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rTI2uKfUaVn for ; Thu, 30 May 2013 07:46:14 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id B726921F8616 for ; Thu, 30 May 2013 07:46:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMdkp1HGmAcF/2dsb2JhbABPCoJoIcI/fRZ0giMBAQEBAgESKEQHBAIBCA0EBAEBCxQJBzIUCQgBAQQBEggah2UGAZ5WnD8XjWCBCzgGgnBhA51/in+DD4In X-IronPort-AV: E=Sophos;i="4.87,770,1363147200"; d="scan'208";a="11293281" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 May 2013 10:46:03 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 May 2013 10:40:23 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Thu, 30 May 2013 10:46:00 -0400 From: "Romascanu, Dan (Dan)" To: "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5dQQpmrX+eILrVQJu06CxfDKZpagAAPk1A Date: Thu, 30 May 2013 14:46:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17BB99@AZ-FFEXMB04.global.avaya.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:46:20 -0000 Hi Barbara,=20 > Who is asking for IETF to ensure protocol-level interoperability among > these components? Well, this is what most of the work in the IETF is about - achieving on-the= -wire interoperability.=20 > But a consistent data model across all of them -- that's big. The top thi= ng on my IETF wish list is the data model -- both a generic model that coul= d be used by other orgs to create data models for their protocols, and spec= ific SNMP, netconf, and other IETF-defined protocol data models. Can you explain what you exactly mean by a 'consistent data model'? You are= talking about a range of protocols that spans from=20 > IPDR (for reporting), OMA-DM (for control and reporting), SNMP (for > control and reporting), netconf (for control and reporting), IPFIX (for > reporting), etc. There is no data modeling language that would allow to write one data model= for all these protocols. How can a 'consistent data model' be written in t= he absence of a common DML?=20 Maybe you mean an Information Model? Please refer to RFC 3444 which talks '= On the Difference between Information Models and Data Models' - the way we = use these terms in the IETF. Do you mean that the IETF should focus on deve= loping the Information Models, and maybe some specific data models for the = protocols under the IETF responsibility (SNMP, NETCONF, IPFIX)? Thanks and Regards, Dan > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Thursday, May 30, 2013 5:22 PM > To: Romascanu, Dan (Dan); lmap@ietf.org > Subject: RE: lmap charter - draft 2 >=20 > > Even if the scope of the initial phase of LMAP is designed on the > > assumption that the measurement system is under the control of a > > single organization, its components (controllers, MAs, collectors) may > > originate from different sources (vendors of equipment and > > applications). How will we ensure interoperability between these > > components if we do not define/select at least one > > mandatory-to-implement set of protocols and associated data models? >=20 > Who is asking for IETF to ensure protocol-level interoperability among > these components? > I'm definitely not. In my reading of posts of other potential procurers > of these measurement systems, I haven't seen any potential procurer ask > for this. I could be wrong. If there are service providers who are > actively wanting IETF to tell them what protocols to use, I'd like for > them to say so. >=20 > Here is why I think this is a bad idea. > IMO, the right protocols to use with any given MA depend on a number of > factors: > - Location of the physical device (inside an end user network, or > inside a SP network -- note that not all measurements that SPs want to > run are intended for end user or regulatory consumption; some are > intended for the SP only) > - Whether or not the underlying physical device is managed by the same > MA entity, and what management (bootstrap) protocol is being used for > the ones that are managed by that same entity > - Whether or not the underlying physical device is dedicated to the > purpose of measurements; if measurements is not the main purpose of the > physical device, then the vendor of that device will have a large say in > selecting protocols based on what the vendor is comfortable > implementing. > - The nature of the actual measurement tests that are to be run > - The preferences of the MA entity (who makes the purchase decisions) >=20 > IMO, there are a number of cases where I would recommend TR-069 as the > right protocol for control and reporting. I intend to work with BBF to > ensure TR-069 can be used for this, in case my employer would like to do > that. Other protocols that may be "right" for various conditions include > IPDR (for reporting), OMA-DM (for control and reporting), SNMP (for > control and reporting), netconf (for control and reporting), IPFIX (for > reporting), etc. I already know that the protocols I intend to recommend > to my employer are not the same as what some other providers intend to > use. From what I can see, all providers are intending to use the > protocols that they consider right for them. >=20 > There is no "one size fits all" protocol answer. Trying to cram an IETF- > defined (because I'm pretty sure IETF would never consider mandating a > protocol that was Not Invented Here) protocol down the throats of > service providers and vendors will create ill will and mistrust and > would be futile (because IETF RFCs can easily be ignored -- SPs assign > more decision-making weight to "what's right for me" than they assign to > IETF RFCs). >=20 > In short, the protocols that are implemented on different devices and > network elements will be determined by their procurer and/or the > supplier. If we can get interoperable data models and consistency in the > parameters used as inputs and outputs of test suites, then it really > doesn't matter what the control and reporting protocols are. I've seen > vendors swap out or support multiple protocols with little pain. Often, > multiple protocols are implemented in chip vendor SoCs. But a consistent > data model across all of them -- that's big. The top thing on my IETF > wish list is the data model -- both a generic model that could be used > by other orgs to create data models for their protocols, and specific > SNMP, netconf, and other IETF-defined protocol data models. >=20 > My recommendation to IETF wrt actually trying to mandate protocols is > "don't go there". The bandwidth spent on the protocol religious debate > will impact time available for useful work, and the religious arguments > will likely cause mistrust and hard feelings that will impact people's > willingness to do the useful work. If IETF is successful in publishing > something (because people like me will step back and let the religious > pundits publish what they want -- knowing that it's easier to ignore the > resulting RFC, than it is to engage in a religious war), the resulting > RFC will be ignored by any and all who choose not to adhere to that > religion. >=20 > With that said, a potentially useful exercise would be to identify which > protocols would be better suited to different environments (based on > some of the criteria I listed above). But this could be done without > attempting to express it as a mandate. This could be presented in the > form of useful guidance, as opposed to a religious mandate. > Barbara From j.schoenwaelder@jacobs-university.de Thu May 30 08:01:54 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD3D21F85E8 for ; Thu, 30 May 2013 08:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTqR-TawKWMy for ; Thu, 30 May 2013 08:01:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 024D321F9254 for ; Thu, 30 May 2013 08:01:18 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A45B20BE2; Thu, 30 May 2013 17:01:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id llzoOjLUapBS; Thu, 30 May 2013 17:01:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A14E20BDF; Thu, 30 May 2013 17:01:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ADD68268C5F3; Thu, 30 May 2013 17:01:10 +0200 (CEST) Date: Thu, 30 May 2013 17:01:10 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20130530150110.GA61242@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:01:54 -0000 On Thu, May 30, 2013 at 02:22:02PM +0000, STARK, BARBARA H wrote: > Who is asking for IETF to ensure protocol-level interoperability > among these components? Some people apparently are interested to be able to buy MAs that interoperate on the wire. > If there are service providers who are actively wanting IETF to tell > them what protocols to use, I'd like for them to say so. At the end of the day, the success of an IETF effort is decided in the market place and everybody will be free to decide whether a standard is useful to implement or deploy. Your notion of "the IETF is telling operators what to deploy" sounds a bit detached from reality. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bs7652@att.com Thu May 30 09:47:43 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9D221F9254 for ; Thu, 30 May 2013 09:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlK2FGQsjVCr for ; Thu, 30 May 2013 09:47:36 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id B7E1C21F9273 for ; Thu, 30 May 2013 09:47:36 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 8a287a15.2aab02c5d940.75265.00-574.215062.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 30 May 2013 16:47:36 +0000 (UTC) X-MXL-Hash: 51a782a836a57cdf-c6e25902e39b2863d4eb37b28d0d0b370b55c881 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 6a287a15.0.75248.00-335.215003.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 30 May 2013 16:47:35 +0000 (UTC) X-MXL-Hash: 51a782a75e9d3966-be25b184b938ee7e3ec424d1b9912f0676f63c6d Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UGlYVC010190; Thu, 30 May 2013 12:47:34 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UGlVIw010174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 12:47:33 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 30 May 2013 16:47:22 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0342.003; Thu, 30 May 2013 12:47:24 -0400 From: "STARK, BARBARA H" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUAAJOM4AAARqTyA= Date: Thu, 30 May 2013 16:47:24 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CB183@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA17BB99@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA17BB99@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.70.109.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=OICQK1mB c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=3-4K8_7RpNEA:10 a=NuZxi4Up2mcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=jwgqLBMEQXgA:10 a=GeemgnRUz1TV7sISPtwA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=_vjogoXgqdkIvH58:21 a=sIjpaF2Ov_cRlGdG:21] Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:47:43 -0000 > Maybe you mean an Information Model? Please refer to RFC 3444 which > talks 'On the Difference between Information Models and Data Models' - th= e > way we use these terms in the IETF. Do you mean that the IETF should focu= s > on developing the Information Models, and maybe some specific data > models for the protocols under the IETF responsibility (SNMP, NETCONF, > IPFIX)? Thanks for the pointer to RFC 3444. That's a useful distinction.=20 Yes, I think it would be very useful and much appreciated if IETF created a= n Information Model, and specific Data Models for IETF protocols where ther= e is demand to use those protocols for control and/or reporting purposes. Barbara From bs7652@att.com Thu May 30 09:54:11 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB09321F8D70 for ; Thu, 30 May 2013 09:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkwAB5DZU-tH for ; Thu, 30 May 2013 09:54:04 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5F421F8700 for ; Thu, 30 May 2013 09:54:04 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id c2487a15.2aaad8419940.259971.00-580.738089.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 30 May 2013 16:54:04 +0000 (UTC) X-MXL-Hash: 51a7842c75a4f16b-f793a8cd2cc04c3f8dacf4e2a9716365586a03dd Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id a2487a15.0.259950.00-292.738013.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 30 May 2013 16:54:03 +0000 (UTC) X-MXL-Hash: 51a7842b669b9034-f6bb75e8a3133f69dd8c6eb05b8730833a76662e Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UGs0gM015414; Thu, 30 May 2013 12:54:02 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UGrkeN015174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 12:53:57 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 30 May 2013 16:53:39 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0342.003; Thu, 30 May 2013 12:53:41 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUAAJwGcAAAgZ85A= Date: Thu, 30 May 2013 16:53:40 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CB1A4@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130530150110.GA61242@elstar.local> In-Reply-To: <20130530150110.GA61242@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.109.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=AaYG6QrG c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=3-4K8_7RpNEA:10 a=dpDthlLKJOUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=r-i3oeFjtK8A:10 a=0SrFBF1Tm4-4k0FZyigA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=kuQWNqzNfcMxrqvQ:21 a=qBp49AwaPsSnJjf3:21] Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:54:11 -0000 > > Who is asking for IETF to ensure protocol-level interoperability among > > these components? >=20 > Some people apparently are interested to be able to buy MAs that > interoperate on the wire. MA to MA operability is not what we are discussing. That comes from the mea= surement protocols, which I think are for ippm to recommend. We're discussi= ng MA to Controller and MA to data Collector interoperability. Since the pr= oposed scope indicates to me that a single entity has total say in selectio= n of an MA and its affiliated systems, that entity will have total say as t= o the nature of its MA to Controller and MA to data Collector interfaces. M= y question remains as to whether any of the procurers of these systems are = asking for the IETF to attempt to dictate to them what protocols must be im= plemented and run on those management interfaces. > > If there are service providers who are actively wanting IETF to tell > > them what protocols to use, I'd like for them to say so. >=20 > At the end of the day, the success of an IETF effort is decided in the ma= rket > place and everybody will be free to decide whether a standard is useful t= o > implement or deploy. Your notion of "the IETF is telling operators what t= o > deploy" sounds a bit detached from reality. You are right that the success of an IETF effort is decided in the market p= lace. I believe that there is no market for control and reporting protocol = mandates (from IETF or any other org). The potential procurers of these sys= tems are not requesting that IETF produce a mandate for control and reporti= ng protocols. Given the freedom of these procurers to select what they wish= , and the lack of any such request from them, why would IETF choose to proc= eed with such an effort? =20 The notion of "the IETF is telling operators what to deploy" is, unfortunat= ely, not detached from reality. I have difficulty counting the number of ti= mes I have seen individual contributors to IETF express the view that IETF = should do more to force operators to bend to the collective will of IETF. I= often see operators insulted and chastised for ignoring this collective wi= ll. They frequently ask "How can we force operators to do what we want?" an= d say things like "Maybe if we write or do x, the regulators will force the= operators, or the people will rise up in revolt against the operators." I'= ve also seen statements of "Operators are asking for x, but if we refuse to= put x in a spec, then they will have no choice but to implement the spec w= ithout x." And then these IETF contributors lambast the stupidity of the p= eople for not rising up in revolt, and the regulators for not enforcing the= IETF's will. Right now, I'm trying to get lmap to not put in its scope ele= ments that (IMO) are almost guaranteed to result in these sorts of conversa= tions. In this particular case, operators are the primary intended procurer= s of the systems in question, and operators are not asking IETF to write th= is mandate (and I'm actually actively asking IETF not to write such a manda= te). Given my history of these sorts of discussions in IETF, I regret that = I'm mistrustful of motivations for wanting to proceed with creating such a = mandate. It has to me the look and feel of an exercise where non-operators = want to create a mandate targeted at operators, and where the wishes of ope= rators will be ignored and minimized. I apologize for seeing things this wa= y, but this is how my past experiences have taught me to see things. Barbara From shane@castlepoint.net Thu May 30 11:52:18 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9122021F86CB for ; Thu, 30 May 2013 11:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU6l-b66deC6 for ; Thu, 30 May 2013 11:52:11 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC9121F8904 for ; Thu, 30 May 2013 11:51:32 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id EC182300073 for ; Thu, 30 May 2013 18:51:23 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id BDBA5300028; Thu, 30 May 2013 12:51:22 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Thu, 30 May 2013 12:51:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu May 30 12:51:23 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 51a79fab42071852811950 X-DSPAM-Factors: 27, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, to+#+#+#+to, 0.01000, that+are, 0.01000, that+are, 0.01000, the+#+I, 0.01000, the+#+I, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, to+#+#+in, 0.01000, To*STARK+BARBARA, 0.01000, to+#+to, 0.01000, to+#+to, 0.01000, not+to, 0.01000, Mime-Version*OS+X, 0.01000, bs7652+#+#+wrote, 0.01000, and+or, 0.01000, and+or, 0.01000, up+to, 0.01000, up+to, 0.01000, list+lmap, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, and+other, 0.01000, and+other, 0.01000, a+single, 0.01000, wanted+to, 0.01000 Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 18:52:18 -0000 Barbara, On May 30, 2013, at 8:22 AM, "STARK, BARBARA H" wrote: >> Even if the scope of the initial phase of LMAP is designed on the = assumption >> that the measurement system is under the control of a single = organization, >> its components (controllers, MAs, collectors) may originate from = different >> sources (vendors of equipment and applications). How will we ensure >> interoperability between these components if we do not define/select = at >> least one mandatory-to-implement set of protocols and associated data >> models? >=20 > Who is asking for IETF to ensure protocol-level interoperability among = these components? > I'm definitely not. In my reading of posts of other potential = procurers of these measurement systems, I haven't seen any potential = procurer ask for this. I could be wrong. If there are service providers = who are actively wanting IETF to tell them what protocols to use, I'd = like for them to say so. As per your request, I am speaking up to say: I am, (my affiliation is: = Level 3 Communications)[1]. It is, by far, the most straightforward way = to guarantee (equipment/software) vendors will build solutions that are = on-the-wire interoperable between the various components that will = comprise the overall LMAP architecture, so that I do not have to specify = in excruciatingly specific detail what needs to get done in RFP/RFI's = when I'm attempting to acquire equipment and/or work with third-party = (potentially, already deployed) equipment. Thanks, -shane [1] Note, I do recognize that I appear to be in the minority based on = views presented by other members of the WG mailing list over the past = few months. Nonetheless, I wanted to make it clear that I still think = this is an important/critical consideration for the LMAP work. = Ultimately, though, it is up to the WG co-chairs and AD's to determine = "rough consensus" on this, and other points, relative to the work that a = forthcoming LMAP WG will be tasked with. > Here is why I think this is a bad idea. > IMO, the right protocols to use with any given MA depend on a number = of factors: > - Location of the physical device (inside an end user network, or = inside a SP network -- note that not all measurements that SPs want to = run are intended for end user or regulatory consumption; some are = intended for the SP only) > - Whether or not the underlying physical device is managed by the same = MA entity, and what management (bootstrap) protocol is being used for = the ones that are managed by that same entity > - Whether or not the underlying physical device is dedicated to the = purpose of measurements; if measurements is not the main purpose of the = physical device, then the vendor of that device will have a large say in = selecting protocols based on what the vendor is comfortable = implementing. > - The nature of the actual measurement tests that are to be run > - The preferences of the MA entity (who makes the purchase decisions) >=20 > IMO, there are a number of cases where I would recommend TR-069 as the = right protocol for control and reporting. I intend to work with BBF to = ensure TR-069 can be used for this, in case my employer would like to do = that. Other protocols that may be "right" for various conditions include = IPDR (for reporting), OMA-DM (for control and reporting), SNMP (for = control and reporting), netconf (for control and reporting), IPFIX (for = reporting), etc. I already know that the protocols I intend to recommend = to my employer are not the same as what some other providers intend to = use. =46rom what I can see, all providers are intending to use the = protocols that they consider right for them. >=20 > There is no "one size fits all" protocol answer. Trying to cram an = IETF-defined (because I'm pretty sure IETF would never consider = mandating a protocol that was Not Invented Here) protocol down the = throats of service providers and vendors will create ill will and = mistrust and would be futile (because IETF RFCs can easily be ignored -- = SPs assign more decision-making weight to "what's right for me" than = they assign to IETF RFCs). >=20 > In short, the protocols that are implemented on different devices and = network elements will be determined by their procurer and/or the = supplier. If we can get interoperable data models and consistency in the = parameters used as inputs and outputs of test suites, then it really = doesn't matter what the control and reporting protocols are. I've seen = vendors swap out or support multiple protocols with little pain. Often, = multiple protocols are implemented in chip vendor SoCs. But a consistent = data model across all of them -- that's big. The top thing on my IETF = wish list is the data model -- both a generic model that could be used = by other orgs to create data models for their protocols, and specific = SNMP, netconf, and other IETF-defined protocol data models. >=20 > My recommendation to IETF wrt actually trying to mandate protocols is = "don't go there". The bandwidth spent on the protocol religious debate = will impact time available for useful work, and the religious arguments = will likely cause mistrust and hard feelings that will impact people's = willingness to do the useful work. If IETF is successful in publishing = something (because people like me will step back and let the religious = pundits publish what they want -- knowing that it's easier to ignore the = resulting RFC, than it is to engage in a religious war), the resulting = RFC will be ignored by any and all who choose not to adhere to that = religion. >=20 > With that said, a potentially useful exercise would be to identify = which protocols would be better suited to different environments (based = on some of the criteria I listed above). But this could be done without = attempting to express it as a mandate. This could be presented in the = form of useful guidance, as opposed to a religious mandate. > Barbara > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap >=20 From bs7652@att.com Thu May 30 13:17:17 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB3A21F9254 for ; Thu, 30 May 2013 13:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z3oWj42-pw9 for ; Thu, 30 May 2013 13:17:10 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 935DF21F920B for ; Thu, 30 May 2013 13:17:10 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 6c3b7a15.2aaadde22940.418029.00-534.1182586.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 30 May 2013 20:17:10 +0000 (UTC) X-MXL-Hash: 51a7b3c65f317547-27bc655e21c350321ccada47411a6b5ac09f24db Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id e93b7a15.0.417623.00-078.1181295.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 30 May 2013 20:16:31 +0000 (UTC) X-MXL-Hash: 51a7b39f09d4e337-9672d698d057d252b6a4e5a7306231511ca6b288 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UKGTOa004733; Thu, 30 May 2013 16:16:30 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UKGMXH004664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 16:16:24 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 30 May 2013 20:16:12 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0342.003; Thu, 30 May 2013 16:16:13 -0400 From: "STARK, BARBARA H" To: Shane Amante Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUAARytoAAAYmBDA= Date: Thu, 30 May 2013 20:16:12 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.109.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=E5V6U9hl c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=3-4K8_7RpNEA:10 a=dpDthlLKJOUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=r-i3oeFjtK8A:10 a=SKMwg81zkGcNIwVoeO0A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 20:17:17 -0000 Hi Shane, > >> Even if the scope of the initial phase of LMAP is designed on the > >> assumption that the measurement system is under the control of a > >> single organization, its components (controllers, MAs, collectors) > >> may originate from different sources (vendors of equipment and > >> applications). How will we ensure interoperability between these > >> components if we do not define/select at least one > >> mandatory-to-implement set of protocols and associated data models? > > > > Who is asking for IETF to ensure protocol-level interoperability among > these components? > > I'm definitely not. In my reading of posts of other potential procurers= of > these measurement systems, I haven't seen any potential procurer ask for > this. I could be wrong. If there are service providers who are actively w= anting > IETF to tell them what protocols to use, I'd like for them to say so. >=20 > As per your request, I am speaking up to say: I am, (my affiliation is: L= evel 3 > Communications)[1]. It is, by far, the most straightforward way to guara= ntee > (equipment/software) vendors will build solutions that are on-the-wire > interoperable between the various components that will comprise the > overall LMAP architecture, so that I do not have to specify in excruciati= ngly > specific detail what needs to get done in RFP/RFI's when I'm attempting t= o > acquire equipment and/or work with third-party (potentially, already > deployed) equipment. Fair enough. But since the needs of your employer are not the same as the n= eeds of my employer (and the embedded base of managed devices we have in th= e homes and hands of consumers is likely very different, as are many of the= vendors we use in our networks) may I suggest a compromise approach.=20 Rather than an approach of a standards track RFC that says "To implement th= e lmap architecture, the following protocols are mandatory", how about we t= ake a page out of v6ops and do sort of an "architectural profile"? That is,= create a BCP document that says "For a provider/network/3rd party whose ch= aracteristics are x, this document recommends the lmap architecture be inst= antiated as follows: MA must implement control protocol y and report protoc= ol z, etc." That way, a document could be created that more specifically targets the ne= eds of your employer, without implying that it's the right solution for eve= ryone else. You get an RFC, without argument as to whether the characterist= ics of your employer's network should weigh more heavily as criteria for pr= otocol selection than the characteristics of my employer's network; and I d= on't feel threatened or backed into a corner, forced to argue religion. Wou= ld that work for you? Barbara From Michael.K.Bugenhagen@centurylink.com Thu May 30 13:24:05 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D00321F8F6E for ; Thu, 30 May 2013 13:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+gNVQqePKwP for ; Thu, 30 May 2013 13:23:52 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 13C7121F8F44 for ; Thu, 30 May 2013 13:23:42 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r4UKNbJI011076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 14:23:37 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 8D7441E0068; Thu, 30 May 2013 14:23:32 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 78EDE1E005E; Thu, 30 May 2013 14:23:32 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r4UKNWnM029784; Thu, 30 May 2013 14:23:32 -0600 (MDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r4UKNVMu029766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 14:23:31 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.02.0318.001; Thu, 30 May 2013 15:23:31 -0500 From: "Bugenhagen, Michael K" To: "Romascanu, Dan (Dan)" Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: AQHOXMfnTsjvrj9ZEkKCIggBQ/2LvJkdtEIAgAB5RoQ= Date: Thu, 30 May 2013 20:23:30 +0000 Message-ID: <03E0F392-8210-44B0-A009-8AC96B928557@centurylink.com> References: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E611302CAA0A@GAALPA1MSGUSR9L.ITServices.sbc.com>, <9904FB1B0159DA42B0B887B7FA8119CA17B060@AZ-FFEXMB04.global.avaya.com> <4AA809CE-C6B1-4C85-80F1-0B897405DA04@centurylink.com>, <9904FB1B0159DA42B0B887B7FA8119CA17B408@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA17B408@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 20:24:05 -0000 Sent from my iPhone On May 30, 2013, at 2:09 AM, "Romascanu, Dan (Dan)" wr= ote: > Hi Mike,=20 >=20 > Can you be more specific what you mean by 'interface for the customer'? M= ore exact: > - who is the customer you have in mind?=20 Consumers of the Internet is what I meant here=20 > - what kind of interface needs to be standardized?=20 A consumer should be able to access measurement data which equals an = interface of some sort Thanks Mike >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >> -----Original Message----- >> From: Bugenhagen, Michael K >> [mailto:Michael.K.Bugenhagen@centurylink.com] >> Sent: Thursday, May 30, 2013 2:55 AM >> To: Romascanu, Dan (Dan) >> Cc: STARK, BARBARA H; lmap@ietf.org >> Subject: Re: [lmap] lmap charter - draft 2 >>=20 >> Dan, >>=20 >> I believe we need to put an interface for the customer as part of >> the scope, I agree which protocol that interface uses comes later - >> However the question of creation of an interface should be part of the >> scope conversation. Personally I would like to see the IETF get >> accolades for creating that, So I think it should be part of the >> project. >>=20 >> Thanks >> Mike >>=20 >> Sent from my iPhone >>=20 >> On May 29, 2013, at 2:52 PM, "Romascanu, Dan (Dan)" >> wrote: >>=20 >>> Hi Barbara, >>>=20 >>> Even if the scope of the initial phase of LMAP is designed on the >> assumption that the measurement system is under the control of a single >> organization, its components (controllers, MAs, collectors) may >> originate from different sources (vendors of equipment and >> applications). How will we ensure interoperability between these >> components if we do not define/select at least one mandatory-to- >> implement set of protocols and associated data models? >>>=20 >>> Thanks and Regards, >>>=20 >>> Dan >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: STARK, BARBARA H [mailto:bs7652@att.com] >>>> Sent: Wednesday, May 29, 2013 10:30 PM >>>> To: Romascanu, Dan (Dan); lmap@ietf.org >>>> Subject: RE: lmap charter - draft 2 >>>>=20 >>>> Sorry I didn't manage to write my comments last week. I kept running >>>> out of time, because I didn't want to just throw my comments over the >>>> wall without suggesting language. >>>>=20 >>>> I have a big concern about language in the charter that suggests lmap >>>> will standardize The Protocols to Be Used, and suggestions that this >>>> would be particularly useful. I think that attempting to pick The >>>> Protocols to Be Used would result in a futile religious war. It's >>>> futile because we've agreed that the MA, Controller and Collector are >>>> all under a single administrative domain -- so whoever owns that >>>> domain will select the protocols they will use. I would prefer if the >>>> charter were to identify existing IETF-defined protocols that *can* >>>> be used, describe any nuances to their use for lmap purposes, define >>>> extensions as necessary, and define any data models that would be >>>> needed to use them for lmap purposes. All without any hint or >>>> suggestion to imply they >>>> *must* be used. And before doing that, requirements for what >>>> constitutes a good protocol would also be useful. Such requirements >>>> can not only be used to identify the gaps in existing IETF protocols, >>>> but would also be useful to any "domain administrators" in developing >>>> criteria for what they need out of a protocol that is used in systems >>>> they procure (that wasn't invented here). >>>>=20 >>>> In addition, I've had people tell me privately that they think my >>>> idea of defining a standard DNS-SD Service Instance for an xml page >>>> on a router that can provide whatever info that router may want to >>>> share about WAN link utilization, its LAN link metrics, service >>>> attributes it may know, etc. would be a good idea. But for some >>>> reason, they don't support the idea publicly on this list. So I'm >>>> going to try one more time to put this in scope. If no-one speaks up, >>>> I'll consider the idea dead here, and will pursue it in BBF. I think >>>> it will be less useful as a BBF-only defined DNS-SD Service Instance, >>>> because I think it would be also useful if off-the-shelf consumer CE >>>> routers (e.g., D-Link, Belkin) could be encouraged to use this to >>>> provide standard-format information about WAN link utilization and >>>> LAN link metrics to home networked devices. But so be it. >>>>=20 >>>>> Standardizing these mechanisms (Control protocol, Report protocol, >>>>> and corresponding data models) will make it possible to incorporate >>>>> interoperable measurement communications into home and enterprise >>>>> edge routers, personal computers, mobile devices and other >>>>> networking devices, whether wired or wireless. Standards will help >>>>> these management capabilities become more pervasive and facilitate >>>>> measurement results that are directly comparable. >>>>=20 >>>> Recommend re-wording to make this focus on the need for requirements >>>> of protocols and not on a specific set of standardized protocols: >>>>=20 >>>> Standardizing the requirements for mechanisms (Control protocol, >>>> Report protocol, and corresponding data models) will ensure that all >>>> protocols that are used for these purposes are capable of controlling >>>> the same set of measurements and reporting the measurement data in a >>>> standardized manner. This will allow for consistency in protocol >>>> capabilities and behavior, without constraining the deploying entity >>>> unnecessarily in protocol selection. It will make it possible to >>>> incorporate interoperable measurement communications into home and >>>> enterprise edge routers, personal computers, mobile devices and other >>>> networking devices, whether wired or wireless. Standardized >>>> requirements will help these management capabilities become more >>>> pervasive and facilitate measurement results that are directly >> comparable. >>>>=20 >>>>> The Large-Scale Measurement of Broadband Performance (LMAP) working >>>>> group is chartered to determine the form of data models and >>>>> select/extend one or more protocols for the communications between >>>>> the Measurement Agents' (MAs) function and their Controller function >>>>> and >>>> Collector function. >>>>> These three functions comprise the LMAP measurement system. >>>>=20 >>>> Recommend adding the protocol requirements as a deliverable, and >>>> limiting the scope of protocol extension to IETF-specified protocols: >>>>=20 >>>> The Large-Scale Measurement of Broadband Performance (LMAP) working >>>> group is chartered to determine protocol requirements, determine the >>>> form of data models and identify/extend one or more IETF-specified >>>> protocols for the communications between the Measurement Agents' >>>> (MAs) function and their Controller function and Collector function. >>>> These three functions comprise the LMAP measurement system. >>>>=20 >>>>> The standardized LMAP mechanisms will allow a Controller to instruct >>>>> MAs what performance metrics to measure, when to measure them, >>>>> how/when to report the measurement results to a Collector, and then >>>>> for the MA to report the results to the Collector. The primary >>>>> products of the working group are the data models that define the >>>>> measurement instructions and reports, and protocols for securely >>>>> delivering these data models to/from the MAs. Data models should be >>>>> extensible for new and additional measurements. >>>>=20 >>>> I recommend: >>>> The requirements for LMAP mechanisms will allow a Controller to >>>> instruct MAs what performance metrics to measure, when to measure >>>> them, how/when to report the measurement results to a Collector, and >>>> then for the MA to report the results to the Collector. The primary >>>> products of the working group are the protocol requirements, the data >>>> models that define the measurement instructions and reports, and >>>> identification/extension of IETF-specified protocols for securely >>>> delivering these data models to/from the MAs. Data models should be >>>> extensible for new and additional measurements. >>>>=20 >>>>> The case where an end user can independently perform network >>>>> diagnostic measurements (beyond their private network) is not >>>>> directly in scope, recognizing that users have many opportunities to >>>>> do this >>>> today. >>>>> However, end users can obtain an MA to run measurement tasks if >>>>> desired and report their results to whomever they want, most likely >>>>> the supplier of the MA. This provides for user-initiated on-demand >>>>> measurement, which is an important component of the ISP use case. >>>>=20 >>>> I would prefer to delete the phrase ", most likely the supplier of >>>> the MA". I actually think the most likely choice here will be for the >>>> end user to report the results to the end user. But I don't think >>>> this point is particular worthy of discussion. >>>>=20 >>>>> Discovering the service parameters on the MAs or sharing the service >>>>> parameters between MAs are out of the scope of the LMAP charter. >>>>> However, if the service parameters are available to the MAs, they >>>>> could be combined with the measurement results in the Report >> Protocol. >>>>=20 >>>> Recommend: >>>> Mechanisms for exchanging service parameters external to an end >>>> user's network is out of scope of the LMAP charter. However, the data >>>> model of these service attributes is in scope, where they could be >>>> combined with the measurement results in the Report Protocol. A >>>> mechanism that would allow a CE Router inside the end user's network >>>> to provide other devices inside the end user network with information >> is in scope. >>>>=20 >>>>> Service parameters, such as product category, can be useful to >>>>> decide which measurements to run and how to interpret the results. >>>>> These parameters are already gathered and stored by existing >>>>> operations systems. Deciding the set of measurements to run is a >>>>> business >>>> decision and is out of scope. >>>>=20 >>>> The last sentence seems out of place, since I don't see how it >>>> relates to the first 2 sentences. I think the last sentence could be >>>> added at the end of a different paragraph, like the one that starts >>>> "It is assumed that different organization's LMAP measurement domains >>>> can overlap..." or the one that starts "Both active and passive >>>> measurements are in scope..." >>>>=20 >>>>> LMAP will consider re-use of existing protocols and data model >>>>> languages in its efforts to produce the following work items: >>>>> - The LMAP Framework - provides common terminology and justifies the >>>>> simplifying constraints >>>> >>>>> - The Control protocol and the associated data model: The definition >>>> of >>>>> how instructions are delivered from a Controller to a MA; this >>>>> includes a Data Model consistent with the Information Model plus a >>>>> transport protocol. This is a simple instruction - response >>>>> protocol, and LMAP will specify how it operates over an existing >>>>> protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). >>>>> - The Report protocol and the associated data model: The definition >>>>> of how the Report is delivered from a MA to a Collector; this >>>>> includes a Data Model consistent with the Information Model plus a >>>>> transport protocol (to be selected, perhaps REST-style HTTP(s) or >> IPFIX). >>>>=20 >>>> As it relates to deliverables, I think the protocol requirements >>>> should be included in the framework, and don't need to be a separate >>>> deliverable. >>>> BTW, the term "transport protocol" kind of threw me in the >>>> description of the protocols. I was wondering if "application >>>> protocol" might be better. >>>> Recommend: >>>> - The LMAP Framework - provides common terminology and justifies the >>>> simplifying constraints. The framework includes requirements for the >>>> Control and Report protocols. >>>>=20 >>>> - The Control protocol and the associated data model: The definition >>>> of how instructions are delivered from a Controller to a MA; this >>>> includes a Data Model consistent with the Information Model plus >>>> identification/extension of one or more IETF-specified application >>>> protocols. This is a simple instruction - response protocol, and >>>> LMAP will specify how it operates over one or more existing >>>> protocols (perhaps REST-style HTTP(s) or Netconf). >>>> - The Report protocol and the associated data model: The definition >>>> of how the Report is delivered from a MA to a Collector; this >>>> includes a Data Model consistent with the Information Model plus >>>> identification/extension of one or more IETF-specified application >>>> protocols (perhaps REST-style HTTP(s) or IPFIX). >>>>=20 >>>> And add: >>>> - Mechanism to allow a CE Router to provide devices inside the end >>>> user network with various information that could be useful when >>>> analyzing measurement results. >>>>=20 >>>>> Goals and Milestones >>>>> Apr 2014: Initial WG I-D for the Control protocol >>>> Recommend: Apr 2014: Initial WG I-D for the Control protocol(s) >>>>=20 >>>>> Apr 2014: Initial WG I-D for the Report protocol >>>> Recommend: Apr 2014: Initial WG I-D for Report protocol(s) >>>>=20 >>>> Milestone around this same time for the information delivery >> mechanism. >>>>=20 >>>> Barbara >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap From Henning.Schulzrinne@fcc.gov Thu May 30 13:56:13 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BEA21F8681 for ; Thu, 30 May 2013 13:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aXimVmSoorZ for ; Thu, 30 May 2013 13:56:08 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id A6CBF21F900C for ; Thu, 30 May 2013 13:55:59 -0700 (PDT) Received: from gatekeeper4.fcc.gov (HELO p2pxcas01.fccnet.win.fcc.gov) ([192.104.54.21]) by DC-IP-1.fcc.gov with ESMTP; 30 May 2013 16:55:53 -0400 Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas01.fccnet.win.fcc.gov ([fe80::1d27:de47:ad2e:9062%13]) with mapi id 14.01.0438.000; Thu, 30 May 2013 16:55:53 -0400 From: Henning Schulzrinne To: "'Romascanu, Dan (Dan)'" , "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5caOfRrX+eILrVQJu06CxfDKZpagAKmuQQAASHtDAANI0f0A== Date: Thu, 30 May 2013 20:55:52 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E611302CAA0A@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA17B060@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA17B060@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [165.135.229.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 20:56:13 -0000 A good example are DOCSIS cable modems - consumers can and do buy those at = retail, and they are portable across ISPs. The same is true for DSL modems = in Europe, which are routinely bought from third parties (FritzBox being on= e example). -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Rom= ascanu, Dan (Dan) Sent: Wednesday, May 29, 2013 3:52 PM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] lmap charter - draft 2 Hi Barbara,=20 Even if the scope of the initial phase of LMAP is designed on the assumptio= n that the measurement system is under the control of a single organization= , its components (controllers, MAs, collectors) may originate from differen= t sources (vendors of equipment and applications). How will we ensure inter= operability between these components if we do not define/select at least on= e mandatory-to-implement set of protocols and associated data models?=20 Thanks and Regards, Dan > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Wednesday, May 29, 2013 10:30 PM > To: Romascanu, Dan (Dan); lmap@ietf.org > Subject: RE: lmap charter - draft 2 >=20 > Sorry I didn't manage to write my comments last week. I kept running=20 > out of time, because I didn't want to just throw my comments over the=20 > wall without suggesting language. >=20 > I have a big concern about language in the charter that suggests lmap=20 > will standardize The Protocols to Be Used, and suggestions that this=20 > would be particularly useful. I think that attempting to pick The=20 > Protocols to Be Used would result in a futile religious war. It's=20 > futile because we've agreed that the MA, Controller and Collector are=20 > all under a single administrative domain -- so whoever owns that=20 > domain will select the protocols they will use. I would prefer if the=20 > charter were to identify existing IETF-defined protocols that *can* be=20 > used, describe any nuances to their use for lmap purposes, define=20 > extensions as necessary, and define any data models that would be=20 > needed to use them for lmap purposes. All without any hint or=20 > suggestion to imply they > *must* be used. And before doing that, requirements for what=20 > constitutes a good protocol would also be useful. Such requirements=20 > can not only be used to identify the gaps in existing IETF protocols,=20 > but would also be useful to any "domain administrators" in developing=20 > criteria for what they need out of a protocol that is used in systems=20 > they procure (that wasn't invented here). >=20 > In addition, I've had people tell me privately that they think my idea=20 > of defining a standard DNS-SD Service Instance for an xml page on a=20 > router that can provide whatever info that router may want to share=20 > about WAN link utilization, its LAN link metrics, service attributes=20 > it may know, etc. would be a good idea. But for some reason, they=20 > don't support the idea publicly on this list. So I'm going to try one=20 > more time to put this in scope. If no-one speaks up, I'll consider the=20 > idea dead here, and will pursue it in BBF. I think it will be less=20 > useful as a BBF-only defined DNS-SD Service Instance, because I think=20 > it would be also useful if off-the-shelf consumer CE routers (e.g.,=20 > D-Link, Belkin) could be encouraged to use this to provide=20 > standard-format information about WAN link utilization and LAN link=20 > metrics to home networked devices. But so be it. >=20 > > Standardizing these mechanisms (Control protocol, Report protocol,=20 > > and corresponding data models) will make it possible to incorporate=20 > > interoperable measurement communications into home and enterprise=20 > > edge routers, personal computers, mobile devices and other=20 > > networking devices, whether wired or wireless. Standards will help=20 > > these management capabilities become more pervasive and facilitate=20 > > measurement results that are directly comparable. >=20 > Recommend re-wording to make this focus on the need for requirements=20 > of protocols and not on a specific set of standardized protocols: >=20 > Standardizing the requirements for mechanisms (Control protocol,=20 > Report protocol, and corresponding data models) will ensure that all=20 > protocols that are used for these purposes are capable of controlling=20 > the same set of measurements and reporting the measurement data in a=20 > standardized manner. This will allow for consistency in protocol=20 > capabilities and behavior, without constraining the deploying entity=20 > unnecessarily in protocol selection. It will make it possible to=20 > incorporate interoperable measurement communications into home and=20 > enterprise edge routers, personal computers, mobile devices and other=20 > networking devices, whether wired or wireless. Standardized=20 > requirements will help these management capabilities become more=20 > pervasive and facilitate measurement results that are directly comparable= . >=20 > > The Large-Scale Measurement of Broadband Performance (LMAP) working=20 > > group is chartered to determine the form of data models and=20 > > select/extend one or more protocols for the communications between=20 > > the Measurement Agents' (MAs) function and their Controller function=20 > > and > Collector function. > > These three functions comprise the LMAP measurement system. >=20 > Recommend adding the protocol requirements as a deliverable, and=20 > limiting the scope of protocol extension to IETF-specified protocols: >=20 > The Large-Scale Measurement of Broadband Performance (LMAP) working=20 > group is chartered to determine protocol requirements, determine the=20 > form of data models and identify/extend one or more IETF-specified=20 > protocols for the communications between the Measurement Agents' (MAs)=20 > function and their Controller function and Collector function. These=20 > three functions comprise the LMAP measurement system. >=20 > > The standardized LMAP mechanisms will allow a Controller to instruct=20 > > MAs what performance metrics to measure, when to measure them,=20 > > how/when to report the measurement results to a Collector, and then=20 > > for the MA to report the results to the Collector. The primary=20 > > products of the working group are the data models that define the=20 > > measurement instructions and reports, and protocols for securely=20 > > delivering these data models to/from the MAs. Data models should be=20 > > extensible for new and additional measurements. >=20 > I recommend: > The requirements for LMAP mechanisms will allow a Controller to=20 > instruct MAs what performance metrics to measure, when to measure=20 > them, how/when to report the measurement results to a Collector, and=20 > then for the MA to report the results to the Collector. The primary=20 > products of the working group are the protocol requirements, the data=20 > models that define the measurement instructions and reports, and=20 > identification/extension of IETF-specified protocols for securely=20 > delivering these data models to/from the MAs. Data models should be=20 > extensible for new and additional measurements. >=20 > > The case where an end user can independently perform network=20 > > diagnostic measurements (beyond their private network) is not=20 > > directly in scope, recognizing that users have many opportunities to=20 > > do this > today. > > However, end users can obtain an MA to run measurement tasks if=20 > > desired and report their results to whomever they want, most likely=20 > > the supplier of the MA. This provides for user-initiated on-demand=20 > > measurement, which is an important component of the ISP use case. >=20 > I would prefer to delete the phrase ", most likely the supplier of the=20 > MA". I actually think the most likely choice here will be for the end=20 > user to report the results to the end user. But I don't think this=20 > point is particular worthy of discussion. >=20 > > Discovering the service parameters on the MAs or sharing the service=20 > > parameters between MAs are out of the scope of the LMAP charter. > > However, if the service parameters are available to the MAs, they=20 > > could be combined with the measurement results in the Report Protocol. >=20 > Recommend: > Mechanisms for exchanging service parameters external to an end user's=20 > network is out of scope of the LMAP charter. However, the data model=20 > of these service attributes is in scope, where they could be combined=20 > with the measurement results in the Report Protocol. A mechanism that=20 > would allow a CE Router inside the end user's network to provide other=20 > devices inside the end user network with information is in scope. >=20 > > Service parameters, such as product category, can be useful to=20 > > decide which measurements to run and how to interpret the results.=20 > > These parameters are already gathered and stored by existing=20 > > operations systems. Deciding the set of measurements to run is a=20 > > business > decision and is out of scope. >=20 > The last sentence seems out of place, since I don't see how it relates=20 > to the first 2 sentences. I think the last sentence could be added at=20 > the end of a different paragraph, like the one that starts "It is=20 > assumed that different organization's LMAP measurement domains can=20 > overlap..." or the one that starts "Both active and passive=20 > measurements are in scope..." >=20 > > LMAP will consider re-use of existing protocols and data model=20 > > languages in its efforts to produce the following work items: > > - The LMAP Framework - provides common terminology and justifies the=20 > > simplifying constraints > > > - The Control protocol and the associated data model: The definition > of > > how instructions are delivered from a Controller to a MA; this > > includes a Data Model consistent with the Information Model plus a > > transport protocol. This is a simple instruction - response > > protocol, and LMAP will specify how it operates over an existing > > protocol (to be selected, perhaps REST-style HTTP(s) or Netconf). > > - The Report protocol and the associated data model: The definition of > > how the Report is delivered from a MA to a Collector; this includes > > a Data Model consistent with the Information Model plus a transport > > protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). >=20 > As it relates to deliverables, I think the protocol requirements=20 > should be included in the framework, and don't need to be a separate=20 > deliverable. > BTW, the term "transport protocol" kind of threw me in the description=20 > of the protocols. I was wondering if "application protocol" might be=20 > better. > Recommend: > - The LMAP Framework - provides common terminology and justifies the=20 > simplifying constraints. The framework includes requirements for the=20 > Control and Report protocols. >=20 > - The Control protocol and the associated data model: The definition of > how instructions are delivered from a Controller to a MA; this > includes a Data Model consistent with the Information Model plus=20 > identification/extension of one or more IETF-specified > application protocols. This is a simple instruction - response > protocol, and LMAP will specify how it operates over one or more=20 > existing > protocols (perhaps REST-style HTTP(s) or Netconf). > - The Report protocol and the associated data model: The definition of > how the Report is delivered from a MA to a Collector; this includes > a Data Model consistent with the Information Model plus=20 > identification/extension of one or more IETF-specified > application protocols (perhaps REST-style HTTP(s) or IPFIX). >=20 > And add: > - Mechanism to allow a CE Router to provide devices inside the end=20 > user network with various information that could be useful when=20 > analyzing measurement results. >=20 > > Goals and Milestones > > Apr 2014: Initial WG I-D for the Control protocol > Recommend: Apr 2014: Initial WG I-D for the Control protocol(s) >=20 > > Apr 2014: Initial WG I-D for the Report protocol > Recommend: Apr 2014: Initial WG I-D for Report protocol(s) >=20 > Milestone around this same time for the information delivery mechanism. >=20 > Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Fri May 31 02:12:33 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE4021F8FA9 for ; Fri, 31 May 2013 02:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEh8g1pgK8GL for ; Fri, 31 May 2013 02:12:29 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3C87321F8DDD for ; Fri, 31 May 2013 02:12:29 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 31 May 2013 10:12:27 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.58]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Fri, 31 May 2013 10:12:27 +0100 From: To: , Date: Fri, 31 May 2013 10:12:25 +0100 Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUAARytoAAAYmBDAADYSoIA== Message-ID: <9510D26531EF184D9017DF24659BB87F34B5414E3E@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dromasca@avaya.com, lmap@ietf.org Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 09:12:33 -0000 Barbara, all, I work for BT and believe we also would like protocol-level interoperabilit= y.=20 The case we're particularly interested in is where MAs are embedded in home= gateways. They're dual sourced and the selection of vendors changes from o= ne cycle to another. The MAs would interact with the BT-run Controller and = Collector, which may be from another vendor that specialises in network man= agement.=20 I don't take the current language to mean it's mandatory to implement for a= ll ISPs, regulators etc. I'm happy for Dan, Al and Benoit to decide about r= e-phrasings.=20 I think in practice the IETF will extend or re-use an existing IETF protoco= l and not a Broadband Forum protocol like TR-069. I agree with you (Barbara) that specifying the (generic) Information Model = is very useful and a key work item. If we get this right, then ISPs (or oth= er standards bodies) that don't want to use the IETF protocol will still ho= pefully use the same Information Model. << Recommend re-wording to make this focus on the need for requirements of = protocols and not on a specific set of standardized protocols:>> Depends what you mean by 'requirements'. Personally I think that the IETF is bad at doing requirements - they often = seem to turn into large shopping lists that delay the protocol work and any= way aren't followed through (whereas other SDOs have a top-down process whe= re the requirements formally determine the protocol).=20 For me, what matters is reaching agreement on what we're trying to do (you = could call this the high-level requirements or the top 2 or 3 requirements)= - what are the constraints (like the single organisation assumption, and t= here will be a lot of MAs) - and roughly how to do it (could call this the = high-level architecture). This would be recorded in the framework doc. Pers= onally I think this would also be a good moment to reach (and record) conse= nsus on what protocol (or protocols) will be re-used or extended. I also think it's good practice for the later documents to record why the s= tandard is like it is (for example in an Informational appendix). I think t= his would be useful for ISPs and other SDOs that want to use something othe= r than the LMAP-defined protocol. I think doing these two things, along with the generic Information Model, w= ould fulfil what you want=20 << In addition, I've had people tell me privately that they think my idea o= f defining a standard DNS-SD Service Instance for an xml page on a router t= hat can provide whatever info that router may want to share about WAN link = utilization, its LAN link metrics, service attributes it may know, etc. wou= ld be a good idea. >> I think this could be useful, but don't think I'll have effort to work on i= t. A couple of comments - At the moment the Charter is tightly focussed on the MA's interactions wi= th the Controller and Collector. This work would be a different interface, = between the home gateway (customer edge router) and other devices in the ho= me network. - could this be something that the homenet wg would be interested in? it's = not a wg I follow, but name resolution and service discovery are mentioned = in the charter. Their architecture doc is currently in last call. http://da= tatracker.ietf.org/wg/homenet/=20 I think your other comments are re-phrasings. I'm happy for Dan, Al and Ben= oit to decide about them. Thanks phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > STARK, BARBARA H > Sent: 30 May 2013 21:16 > To: Shane Amante > Cc: Romascanu, Dan (Dan); lmap@ietf.org > Subject: Re: [lmap] lmap charter - draft 2 >=20 > Hi Shane, > > >> Even if the scope of the initial phase of LMAP is designed on the > > >> assumption that the measurement system is under the control of a > > >> single organization, its components (controllers, MAs, collectors) > > >> may originate from different sources (vendors of equipment and > > >> applications). How will we ensure interoperability between these > > >> components if we do not define/select at least one > > >> mandatory-to-implement set of protocols and associated data > models? > > > > > > Who is asking for IETF to ensure protocol-level interoperability > > > among > > these components? > > > I'm definitely not. In my reading of posts of other potential > > > procurers of > > these measurement systems, I haven't seen any potential procurer ask > > for this. I could be wrong. If there are service providers who are > > actively wanting IETF to tell them what protocols to use, I'd like > for them to say so. > > > > As per your request, I am speaking up to say: I am, (my affiliation > > is: Level 3 Communications)[1]. It is, by far, the most > > straightforward way to guarantee > > (equipment/software) vendors will build solutions that are on-the- > wire > > interoperable between the various components that will comprise the > > overall LMAP architecture, so that I do not have to specify in > > excruciatingly specific detail what needs to get done in RFP/RFI's > > when I'm attempting to acquire equipment and/or work with third-party > > (potentially, already > > deployed) equipment. >=20 > Fair enough. But since the needs of your employer are not the same as > the needs of my employer (and the embedded base of managed devices we > have in the homes and hands of consumers is likely very different, as > are many of the vendors we use in our networks) may I suggest a > compromise approach. >=20 > Rather than an approach of a standards track RFC that says "To > implement the lmap architecture, the following protocols are > mandatory", how about we take a page out of v6ops and do sort of an > "architectural profile"? That is, create a BCP document that says "For > a provider/network/3rd party whose characteristics are x, this document > recommends the lmap architecture be instantiated as follows: MA must > implement control protocol y and report protocol z, etc." >=20 > That way, a document could be created that more specifically targets > the needs of your employer, without implying that it's the right > solution for everyone else. You get an RFC, without argument as to > whether the characteristics of your employer's network should weigh > more heavily as criteria for protocol selection than the > characteristics of my employer's network; and I don't feel threatened > or backed into a corner, forced to argue religion. Would that work for > you? > Barbara > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Fri May 31 06:07:25 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C2521F8825 for ; Fri, 31 May 2013 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KAArBIqdwvr for ; Fri, 31 May 2013 06:07:18 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id CDC0921F8746 for ; Fri, 31 May 2013 06:07:17 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 580a8a15.7340e940.127366.00-550.348810.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 31 May 2013 13:07:17 +0000 (UTC) X-MXL-Hash: 51a8a08501704ab5-68fd8bb24e00d26ca9bcbe73f4d3c0c6ff089752 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 480a8a15.0.127349.00-444.348758.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 31 May 2013 13:07:17 +0000 (UTC) X-MXL-Hash: 51a8a0850d831435-44b61fe965256531c04291348bf4838982646bb1 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4VD7GnW020958; Fri, 31 May 2013 09:07:16 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4VD74Pn020820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 09:07:11 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 31 May 2013 13:06:41 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0342.003; Fri, 31 May 2013 09:06:43 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "shane@castlepoint.net" Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUAARytoAAAYmBDAADYSoIAAIkK9Q Date: Fri, 31 May 2013 13:06:42 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CBCCE@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <9510D26531EF184D9017DF24659BB87F34B5414E3E@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F34B5414E3E@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.82.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=QrDpKyOd c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=G_PeIll0REcA:10 a=dpDthlLKJOUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=r-i3oeFjtK8A:10 a=CW_T-_WC6fGhQm32J5UA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=lcbxbA-gMlq4D3t7:21 a=SSnK3ONHEg0lEfmb:21] Cc: "dromasca@avaya.com" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 13:07:25 -0000 Hi Phil, > I work for BT and believe we also would like protocol-level interoperabil= ity. And do you believe that the only way to achieve protocol-level interoperabi= lity is for the IETF to "ensure" it by creating a standards-track RFC with = mandatory-to-implement protocols listed? Or might there be other ways to ac= hieve this? > The case we're particularly interested in is where MAs are embedded in > home gateways. They're dual sourced and the selection of vendors changes > from one cycle to another. The MAs would interact with the BT-run > Controller and Collector, which may be from another vendor that specialis= es > in network management. >From your description, it sounds like BT is in a position to tell its vendo= rs what protocols to use. Would it not be possible for BT to specify the pr= otocols that BT wants in an RFP, or get together with other European telcos= in HGI or BBF to create a home gateway profile that identifies the mandato= ry-to-implement protocols for BT or for all European telcos? Do you think t= hat the protocols BT or European telcos will want to have implemented are t= he same as what Level3 would want/need, and the same as US cable operators = or US telcos, and that we can all agree on the IETF providing a single stan= dards-track RFC that mandates a single set of protocols for all of us? Beca= use that's *exactly* what's in the charter. A deliverable that defines a ma= ndatory-to-implement "one size fits all" set of protocols.=20 =20 I've suggested an alternate approach of: 1. Define the LMAP data models for all IETF protocols that people agree are= likely to be used for LMAP, 2. For populations who want it, LMAP may define an "architectural profile" = or "device profile" that is a targeted informational or BCP recommendation = of the profiles that are to be used for that specific population. So if the= European telcos wanted IETF to identify the protocols for their devices, t= hey could. And if Level3 wants IETF help to figure out what's right for a L= evel3-type network, that could also be done. And the set of protocols don't= have to be the same. Or the Europeans could do this in HGI or BBF or in th= eir own RFPs. >From your email, I was unclear whether you were in support of the current c= harter proposal of deliverables that identify mandatory-to-implement "one s= ize fits all" control and report protocols. Could you clarify that? The cha= rter currently only has deliverables for data models for these mandatory-to= -implement protocols. I would prefer if there were data model deliverables = for all IETF protocols that people agree are likely to be used for lmap pur= poses (personally, I think SNMP and netconf are both likely as control prot= ocols). Do you disagree with this and want only the data models for the IET= F mandatory-to-implement protocols defined? For example, since that single = control protocol probably wouldn't be SNMP, I guess no SNMP MIB would get d= efined. A protocol comparison guide might be useful. That is, which protocols might= be useful in various networks or devices, depending on characteristics of = those networks or devices. This wouldn't be a top priority for me, but I do= think it could be useful. But this wouldn't be a mandatory-to-implement st= andards-track RFC, either. > I don't take the current language to mean it's mandatory to implement for= all > ISPs, regulators etc. I'm happy for Dan, Al and Benoit to decide about re= - > phrasings. I disagree. The current language is very clear about deliverables that iden= tify "the" control protocol and "the" report protocol, and trying to make t= hese standards track. The language also only has data model deliverables fo= r these 2 protocols, and no others. This isn't just about "re-phrasing". Barbara From bs7652@att.com Fri May 31 06:17:00 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20121F861F for ; Fri, 31 May 2013 06:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhQt6JXL7Qa1 for ; Fri, 31 May 2013 06:16:53 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9043F21F859D for ; Fri, 31 May 2013 06:16:53 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 5c2a8a15.57d04940.114777.00-575.317365.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 31 May 2013 13:16:53 +0000 (UTC) X-MXL-Hash: 51a8a2c554451475-aaeefd050f0af5068386b01ab6ed8e045c441dd8 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 1c2a8a15.0.114757.00-290.317285.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 31 May 2013 13:16:52 +0000 (UTC) X-MXL-Hash: 51a8a2c45647d36d-96b639294a486ec47fbe02128bfd4b012880ca37 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4VDGmeM028819; Fri, 31 May 2013 09:16:49 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4VDGVKM028612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 09:16:33 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 31 May 2013 13:16:20 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Fri, 31 May 2013 09:16:23 -0400 From: "STARK, BARBARA H" To: Henning Schulzrinne , "'Romascanu, Dan (Dan)'" , "lmap@ietf.org" Thread-Topic: lmap charter - draft 2 Thread-Index: Ac5caOfRrX+eILrVQJu06CxfDKZpagAKmuQQAASHtDAANI0f0AAiBHJg Date: Fri, 31 May 2013 13:16:22 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CBCF2@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA17AAF4@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E611302CAA0A@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA17B060@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.82.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Wdm7nTdX c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=G_PeIll0REcA:10 a=NuZxi4Up2mcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=jwgqLBMEQXgA:10 a=-2a8rwMA7domhAOo9EMA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 13:17:00 -0000 > A good example are DOCSIS cable modems - consumers can and do buy > those at retail, and they are portable across ISPs. The same is true for = DSL > modems in Europe, which are routinely bought from third parties (FritzBox > being one example). And is the same set of protocols the right answer for both of these? I suggested to Shane that an "architecture profile" or "device profile" (as= done in v6ops) might be appropriate, that identified the set of protocols = for a particular environment, rather than suggesting that the same protocol= was "right" for all situations. Personally, I would also think that a DOCSIS modem device profile would be = better defined by CableLabs, who has a critical mass of people who understa= nd cable environments, and who could also really and truly ensure interoper= ability through their testing program. Similarly, I think a European DSL mo= dem device profile would be better defined by HGI, who has a critical mass = of experts understanding their environment, and who has a certification pro= gram that can truly ensure interoperability. If the providers who operate i= n these environments want IETF to define device profiles for them, I have n= o objection to that. But if they want to do their profiles in CableLabs or = HGI, I don't think IETF needs to insist on inserting itself into that proce= ss.=20 Barbara From MTooley@NCTA.com Fri May 31 06:53:50 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E14521F8EB1 for ; Fri, 31 May 2013 06:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7zUEnZ5uiMz for ; Fri, 31 May 2013 06:53:42 -0700 (PDT) Received: from mail-3.ncta.com (mail-3.ncta.com [209.23.210.3]) by ietfa.amsl.com (Postfix) with ESMTP id F421D21F969C for ; Fri, 31 May 2013 06:53:19 -0700 (PDT) Received: from MAILSTORE-A.ncta.com ([::1]) by Mailhubcas.ncta.com ([::1]) with mapi id 14.01.0438.000; Fri, 31 May 2013 09:53:15 -0400 From: Matt Tooley To: "STARK, BARBARA H" , Shane Amante Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpmrX+eILrVQJu06CxfDKZpagARytoAAAL2KwAAHIjZAA== Date: Fri, 31 May 2013 13:53:17 +0000 Message-ID: In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [172.23.1.221] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 13:53:50 -0000 +1 on Barbara's comments. The most valuable deliverable is the information/data model. The protocol(s) for interconnecting this should be left to implementor as each SP will have a specific set of requirements that correspond to the uniqueness of their networks. And therefore the suggestion of an "architectural profile" will get more buy-in from SPs electing to implement the framework. -- Matt On 5/30/13 4:16 PM, "STARK, BARBARA H" wrote: >Hi Shane, >> >> Even if the scope of the initial phase of LMAP is designed on the >> >> assumption that the measurement system is under the control of a >> >> single organization, its components (controllers, MAs, collectors) >> >> may originate from different sources (vendors of equipment and >> >> applications). How will we ensure interoperability between these >> >> components if we do not define/select at least one >> >> mandatory-to-implement set of protocols and associated data models? >> > >> > Who is asking for IETF to ensure protocol-level interoperability among >> these components? >> > I'm definitely not. In my reading of posts of other potential >>procurers of >> these measurement systems, I haven't seen any potential procurer ask for >> this. I could be wrong. If there are service providers who are actively >>wanting >> IETF to tell them what protocols to use, I'd like for them to say so. >>=20 >> As per your request, I am speaking up to say: I am, (my affiliation is: >>Level 3 >> Communications)[1]. It is, by far, the most straightforward way to >>guarantee >> (equipment/software) vendors will build solutions that are on-the-wire >> interoperable between the various components that will comprise the >> overall LMAP architecture, so that I do not have to specify in >>excruciatingly >> specific detail what needs to get done in RFP/RFI's when I'm attempting >>to >> acquire equipment and/or work with third-party (potentially, already >> deployed) equipment. > >Fair enough. But since the needs of your employer are not the same as the >needs of my employer (and the embedded base of managed devices we have in >the homes and hands of consumers is likely very different, as are many of >the vendors we use in our networks) may I suggest a compromise approach. > >Rather than an approach of a standards track RFC that says "To implement >the lmap architecture, the following protocols are mandatory", how about >we take a page out of v6ops and do sort of an "architectural profile"? >That is, create a BCP document that says "For a provider/network/3rd >party whose characteristics are x, this document recommends the lmap >architecture be instantiated as follows: MA must implement control >protocol y and report protocol z, etc." > >That way, a document could be created that more specifically targets the >needs of your employer, without implying that it's the right solution for >everyone else. You get an RFC, without argument as to whether the >characteristics of your employer's network should weigh more heavily as >criteria for protocol selection than the characteristics of my employer's >network; and I don't feel threatened or backed into a corner, forced to >argue religion. Would that work for you? >Barbara >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap > From shane@castlepoint.net Fri May 31 07:24:04 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9121F8EDF for ; Fri, 31 May 2013 07:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t996uD23S2lH for ; Fri, 31 May 2013 07:23:58 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id E677921F8689 for ; Fri, 31 May 2013 07:23:57 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 9EF4E30007A for ; Fri, 31 May 2013 14:23:54 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 59971300039; Fri, 31 May 2013 08:23:53 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Fri, 31 May 2013 08:23:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri May 31 08:23:54 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 51a8b27a42076303216425 X-DSPAM-Factors: 27, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, devices+#+#+#+the, 0.01000, is+#+we, 0.01000, that+are, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, to+#+#+in, 0.01000, PM+#+#+#+bs7652, 0.01000, To*STARK+BARBARA, 0.01000, Mime-Version*OS+X, 0.01000, bs7652+#+#+wrote, 0.01000, and+or, 0.01000, and+or, 0.01000, up+to, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, a+single, 0.01000, a+single, 0.01000, we+#+to, 0.01000, the+#+#+#+to, 0.01000, to+#+#+#+that, 0.01000, them+to, 0.01000, From*Amante+shane, 0.01000, PM+#+BARBARA, 0.01000, of+#+is, 0.01000, of+#+is, 0.01000 Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 14:24:04 -0000 Hi Barbara, On May 30, 2013, at 2:16 PM, "STARK, BARBARA H" wrote: > Hi Shane, >>>> Even if the scope of the initial phase of LMAP is designed on the >>>> assumption that the measurement system is under the control of a >>>> single organization, its components (controllers, MAs, collectors) >>>> may originate from different sources (vendors of equipment and >>>> applications). How will we ensure interoperability between these >>>> components if we do not define/select at least one >>>> mandatory-to-implement set of protocols and associated data models? >>>=20 >>> Who is asking for IETF to ensure protocol-level interoperability = among >> these components? >>> I'm definitely not. In my reading of posts of other potential = procurers of >> these measurement systems, I haven't seen any potential procurer ask = for >> this. I could be wrong. If there are service providers who are = actively wanting >> IETF to tell them what protocols to use, I'd like for them to say so. >>=20 >> As per your request, I am speaking up to say: I am, (my affiliation = is: Level 3 >> Communications)[1]. It is, by far, the most straightforward way to = guarantee >> (equipment/software) vendors will build solutions that are = on-the-wire >> interoperable between the various components that will comprise the >> overall LMAP architecture, so that I do not have to specify in = excruciatingly >> specific detail what needs to get done in RFP/RFI's when I'm = attempting to >> acquire equipment and/or work with third-party (potentially, already >> deployed) equipment. >=20 > Fair enough. But since the needs of your employer are not the same as = the needs of my employer (and the embedded base of managed devices we = have in the homes and hands of consumers is likely very different, as = are many of the vendors we use in our networks) may I suggest a = compromise approach.=20 >=20 > Rather than an approach of a standards track RFC that says "To = implement the lmap architecture, the following protocols are mandatory", = how about we take a page out of v6ops and do sort of an "architectural = profile"? That is, create a BCP document that says "For a = provider/network/3rd party whose characteristics are x, this document = recommends the lmap architecture be instantiated as follows: MA must = implement control protocol y and report protocol z, etc." >=20 > That way, a document could be created that more specifically targets = the needs of your employer, without implying that it's the right = solution for everyone else. You get an RFC, without argument as to = whether the characteristics of your employer's network should weigh more = heavily as criteria for protocol selection than the characteristics of = my employer's network; and I don't feel threatened or backed into a = corner, forced to argue religion. Would that work for you? With all due respect, I do not wish to entertain the notion of any type = of "profile", particularly when (in my understanding) you're suggesting = that a profile may contain a unique protocol and/or data-model from = [several] other profiles. In my experience, IETF solutions = (specifically: protocols & data-models) are most successful (i.e.: see = ubiquitous deployment) when a WG creates single standard that vendors = can easily & successfully implement and, of course, operators can = rapidly and inexpensively deploy. My fear is that if we start to go down the road of specifying different = "profiles" (again, which encompass wholly different protocols and/or = data-models), then this will most likely become a tremendous burden for = the entire industry to bear. Ultimately, we can all be more successful = if we collectively agree to implement a single protocol with a single = data-model, because it will have: - much broader choices in terms of equipment/software that can be = procured; - much better economies of scale; - operational excellence because there is only a single = protocol/data-model to "debug"/enhance/etc. by everyone going forward; - few, if any, concerns with having to evolve all "profiles" in = lock-step; - less testing (by vendors & operators) to ensure = interoperability/compatibility between profiles; etc. I acknowledge this will lead to some challenging discussions in order = to, first, narrow down the potential set of protocols and data-models = and, second, make a "rough consensus" call on a single, best overall = protocol + data-model to move forward with. Ultimately, though, this is = why we are all at the IETF, because the goal of the IETF is to design = and engineer a single, best-in-class specification that will see the = broadest adoption possible. Just my $0.02 ... -shane= From bs7652@att.com Fri May 31 08:47:46 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F18521F8E93 for ; Fri, 31 May 2013 08:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3GVYZheZ+be for ; Fri, 31 May 2013 08:47:39 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 19D1C21F8E41 for ; Fri, 31 May 2013 08:47:39 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b16c8a15.6fce3940.241134.00-570.678779.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 31 May 2013 15:47:39 +0000 (UTC) X-MXL-Hash: 51a8c61b77931d2a-1c7b7098110f0d4b702a5fd0ca399963957dee7c Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 716c8a15.0.241113.00-329.678677.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 31 May 2013 15:47:37 +0000 (UTC) X-MXL-Hash: 51a8c6195d9782c4-c9932502bb292be1919bda0a37d6dc84e097710f Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4VFlZBr002736; Fri, 31 May 2013 11:47:35 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4VFlPjt002535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 11:47:30 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 31 May 2013 15:47:11 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0342.003; Fri, 31 May 2013 11:47:13 -0400 From: "STARK, BARBARA H" To: Shane Amante Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUAARytoAAAYmBDAAIsynAAAHK2WA Date: Fri, 31 May 2013 15:47:12 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> In-Reply-To: <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.82.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=E+x6U9hl c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=G_PeIll0REcA:10 a=dpDthlLKJOUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=r-i3oeFjtK8A:10 a=vlzI8biUVvCLB7iUfoAA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=HAclBujenTbezEEM:21 a=B7Btv2yKC78VKTJY:21] Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 15:47:46 -0000 > Ultimately, we can all be more successful if we > collectively agree to implement a single protocol with a single data-mode= l, It's not going to happen. I will not be party to any such agreement. I alre= ady know that I will not be recommending a single protocol for wireless dev= ices, DSL modem/routers, and network elements. I expect to be recommending = (to my employer) that OMA-DM be used as a control protocol for wireless dev= ices, TR-069 as a control protocol for DSL modems/routers, and whatever the= network element vendor implements between their network element and their = Element Management System (EMS) for network elements. Which means I'm not e= ven willing to recommend a single protocol just for the devices and network= elements that exist solely within my employer's environment. Since some of the network element vendors use SNMP and some are wanting to = migrate to netconf, I would really prefer for data models to be defined for= both of these, rather than for just The Mandatory One Protocol (which may = end up being neither of these). Having standard data models for both would = be helpful and useful. The effort to do data models for both would probably= be less than the effort required to pick one over the other (or pick somet= hing different entirely). If you agreed that there could be a different protocol for wireless devices= vs. DSL modems/routers (and leave network elements out of it), then I thin= k it might be possible to select a single protocol for each of these. As lo= ng as it's the one that wireless providers want for wireless devices and th= at DSL providers want for DSL devices, and as long as it doesn't have to be= an IETF protocol. Otherwise, if the providers' wishes are ignored, history= suggests that those providers will completely ignore the recommendation. C= ollective agreement to implement cannot be assumed to result from IETF cons= ensus to publish. Barbara From shane@castlepoint.net Fri May 31 11:28:44 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231EF21F8689 for ; Fri, 31 May 2013 11:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEFJYGEPR2Lz for ; Fri, 31 May 2013 11:28:39 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7340C21F84F9 for ; Fri, 31 May 2013 11:28:39 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id F0333300074 for ; Fri, 31 May 2013 18:28:38 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id E2EA0300027; Fri, 31 May 2013 12:28:37 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Fri, 31 May 2013 12:28:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri May 31 12:28:38 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 51a8ebd642075984818248 X-DSPAM-Factors: 27, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, to+#+#+#+or, 0.01000, be+#+a, 0.01000, and+#+#+#+the, 0.01000, and+#+#+#+the, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, To*STARK+BARBARA, 0.01000, to+#+to, 0.01000, Mime-Version*OS+X, 0.01000, bs7652+#+#+wrote, 0.01000, and+or, 0.01000, and+or, 0.01000, then+I, 0.01000, then+I, 0.01000, not+be, 0.01000, not+be, 0.01000, happen+I, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, the+end, 0.01000, and+other, 0.01000, a+single, 0.01000, a+single, 0.01000, the+#+#+#+to, 0.01000, the+#+#+#+to, 0.01000 Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 18:28:44 -0000 Hi Barbara, On May 31, 2013, at 9:47 AM, "STARK, BARBARA H" wrote: >> Ultimately, we can all be more successful if we >> collectively agree to implement a single protocol with a single = data-model, >=20 > It's not going to happen. I will not be party to any such agreement. I = already know that I will not be recommending a single protocol for = wireless devices, DSL modem/routers, and network elements. I expect to = be recommending (to my employer) that OMA-DM be used as a control = protocol for wireless devices, TR-069 as a control protocol for DSL = modems/routers, and whatever the network element vendor implements = between their network element and their Element Management System (EMS) = for network elements. Which means I'm not even willing to recommend a = single protocol just for the devices and network elements that exist = solely within my employer's environment. >=20 > Since some of the network element vendors use SNMP and some are = wanting to migrate to netconf, I would really prefer for data models to = be defined for both of these, rather than for just The Mandatory One = Protocol (which may end up being neither of these). Having standard data = models for both would be helpful and useful. The effort to do data = models for both would probably be less than the effort required to pick = one over the other (or pick something different entirely). >=20 > If you agreed that there could be a different protocol for wireless = devices vs. DSL modems/routers (and leave network elements out of it), = then I think it might be possible to select a single protocol for each = of these. As long as it's the one that wireless providers want for = wireless devices and that DSL providers want for DSL devices, and as = long as it doesn't have to be an IETF protocol. Otherwise, if the = providers' wishes are ignored, history suggests that those providers = will completely ignore the recommendation. Collective agreement to = implement cannot be assumed to result from IETF consensus to publish. > Barbara I think there's a couple points of disconnect here. First, and perhaps = most fundamentally, the IETF only works on protocol and data-model = specifications and, best current practices that document how a given = protocol/standard the IETF has specified _has_ been successfully = deployed in the Internet. The IETF, as an organization, does not = mandate that any operator anywhere in the world MUST deploy any specific = protocol(s). If you are aware of the IETF making any such = proclamations, then I (and, perhaps, others) would certainly welcome any = examples you can cite.=20 Second, the IETF only has purview to change those standards that it has = created, for example: SNMP, NETCONF/YANG, HTTP(S), data models used = specifically by those protocols, etc. IOW, I believe past precedent has = made it quite clear that the IETF does not "tell" BBF, OMA, IEEE or any = other SDO: a) the IETF has created its own modification to the other = SDO's protocol/data-model; or, b) the IETF mandates that the SDO, under = its own standards-process, must make modifications to the other SDO's = protocols to do X, Y or Z. (In my experience, the IETF may _request_ = another SDO make changes or, much more often, provide clarifications to = the IETF about the other SDO's protocols, but that's as far as things = can and should go). To summarize: 1) The IETF does not mandate an operator deploy IETF standards or any = standard, for that matter. 2) If the IETF does proceed with forming an LMAP WG, then I believe the = IETF should create or, better yet, re-use protocols that it has = ownership _and_ responsibility to maintain, (cf: SNMP, NETCONF/YANG, = HTTP(S), etc.). The benefits should be clear: IETF participants have = expertise with the IETF's own protocols/data-models which allows for = speed and agility to modify them to suit new applications/use-cases = while not breaking backwards compatibility, (unless it has a clear = reason & consensus to do so).=20 3) If individuals in the IETF wish to pursue use of *other* SDO's = protocols and/or data-models, particularly _modifications_ to those = protocols, for one or more functions in LMAP then that activity must = occur within the other SDO's for similar reasons to what I cited in #2. = Further, IMHO, the IETF should attempt to stay away from relying too = heavily on interoperability with other SDO's protocols, because of the = complexity that this creates when attempting to extend or enhance = IETF-owned/controlled protocols. With respect to #3, a compromise I could potentially see is what I think = was first suggested by Phil. Namely, the LMAP WG could be tasked with = coming up with a protocol-neutral "information model" (refer to: = ) for one, or more, components in = the LMAP architecture. Such an "information model" may be the _basis_, = i.e.: high-level guidance, upon which other SDO's use to modify their = own protocols and/or data-models to suit the needs of that SDO's = participants. It would be ideal if we could come up with a minimal = number of informational models that will comprise a small number of LMAP = components/functions, (i.e.: perhaps *just* the configuration and = reporting to/from the MAs), and stick that in as a milestone in the = charter. At the end of the day, from the PoV of the IETF, every network operator = *will* have the freedom of choice to use, for example, a) all = IETF-specified protocols/data-models; b) a mixture of IETF-specified = protocols/data-models *and* other SDO's protocols/data-models; c) all = other SDO's protocols/data-models; or, d) none of the above. IMO, I = have a preference for (a) for my network, but do not wish to hold other = IETF participants back in any way from pursuing, outside the IETF, = standardization and/or deployment using options (b) through (d) = depending on their (network's) needs. Regards, -shane= From bs7652@att.com Fri May 31 12:11:41 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3235921F92C5 for ; Fri, 31 May 2013 12:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iJaaYkxE2Ho for ; Fri, 31 May 2013 12:11:35 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id E9C9F21F99C4 for ; Fri, 31 May 2013 12:11:34 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 6e5f8a15.4e0ad940.373595.00-535.1055750.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 31 May 2013 19:11:34 +0000 (UTC) X-MXL-Hash: 51a8f5e617ef6333-2553ad3b445ae5bcb7e8b721d5c501ecb233bef5 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 295f8a15.0.372547.00-389.1052728.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 31 May 2013 19:10:12 +0000 (UTC) X-MXL-Hash: 51a8f59450bb581f-d0a719d80631b96f7424fd1a31a30986f1644092 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4VJAAOR017591; Fri, 31 May 2013 15:10:10 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4VJA3s4017451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 15:10:05 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 31 May 2013 19:09:46 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Fri, 31 May 2013 15:09:48 -0400 From: "STARK, BARBARA H" To: Shane Amante Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUAARytoAAAYmBDAAIsynAAAHK2WAAAFgsQAAB8IRMA== Date: Fri, 31 May 2013 19:09:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> In-Reply-To: <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.82.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=E+x6U9hl c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=G_PeIll0REcA:10 a=dpDthlLKJOUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=r-i3oeFjtK8A:10 a=XKfbYx4oAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=SvSvcgDgBFly3Yy_2B0A:9 a=CjuIK1q_8ugA:10 a=uI1Or78iWTcA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=XwsyJ7LSQ-J2jSTg] X-AnalysisOut: [:21 a=lrEhoVRGLM4KjYcx:21] Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 19:11:41 -0000 Hi Shane, It sounds like we're very close. Would you agree to the following deliverables? - The LMAP Framework - provides common terminology and justifies the simpli= fying constraints - The LMAP Use Cases - provides the motivating use cases as a basis for the= work - Information Model, the abstract definition of the information carried fro= m the Controller to the MA and the information carried from the MA to the C= ollector. It includes - the metric(s) that can be measured and values for its parameters such as the Peer MA participating in the measurement and the desired environmental conditions (for example, only conduct the measurement when there is no user traffic observed) - the schedule: information elements for defining when the measurement sh= ould be run and how the results should be reported (when and to which Collector) - the report: information elements for identifying the metric(s) measured= and when, the actual result, and supporting metadata such as location. Result reports may be organized in batches or may be reported immediately, such as for an on-demand measurement. - SNMP MIB: Data Model consistent with the Information Model, for control a= nd reporting using SNMP.=20 - NETCONF data model: Data Model consistent with the Information Model, for= control and reporting using NETCONF. And maybe (if people want)... - IPFIX data model: Data Model consistent with the Information Model, for r= eporting using IPFIX. - REST-style HTTP(s) data model: Data Model consistent with the Information= Model, for reporting using REST-style HTTP(s). Barbara > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Friday, May 31, 2013 2:29 PM > To: STARK, BARBARA H > Cc: Romascanu, Dan (Dan); lmap@ietf.org > Subject: Re: [lmap] lmap charter - draft 2 >=20 > Hi Barbara, >=20 > On May 31, 2013, at 9:47 AM, "STARK, BARBARA H" > wrote: > >> Ultimately, we can all be more successful if we collectively agree to > >> implement a single protocol with a single data-model, > > > > It's not going to happen. I will not be party to any such agreement. I = already > know that I will not be recommending a single protocol for wireless devic= es, > DSL modem/routers, and network elements. I expect to be recommending > (to my employer) that OMA-DM be used as a control protocol for wireless > devices, TR-069 as a control protocol for DSL modems/routers, and whateve= r > the network element vendor implements between their network element > and their Element Management System (EMS) for network elements. Which > means I'm not even willing to recommend a single protocol just for the > devices and network elements that exist solely within my employer's > environment. > > > > Since some of the network element vendors use SNMP and some are > wanting to migrate to netconf, I would really prefer for data models to b= e > defined for both of these, rather than for just The Mandatory One Protoco= l > (which may end up being neither of these). Having standard data models fo= r > both would be helpful and useful. The effort to do data models for both > would probably be less than the effort required to pick one over the othe= r > (or pick something different entirely). > > > > If you agreed that there could be a different protocol for wireless dev= ices > vs. DSL modems/routers (and leave network elements out of it), then I thi= nk > it might be possible to select a single protocol for each of these. As lo= ng as it's > the one that wireless providers want for wireless devices and that DSL > providers want for DSL devices, and as long as it doesn't have to be an I= ETF > protocol. Otherwise, if the providers' wishes are ignored, history sugges= ts > that those providers will completely ignore the recommendation. Collectiv= e > agreement to implement cannot be assumed to result from IETF consensus > to publish. > > Barbara >=20 > I think there's a couple points of disconnect here. First, and perhaps m= ost > fundamentally, the IETF only works on protocol and data-model > specifications and, best current practices that document how a given > protocol/standard the IETF has specified _has_ been successfully deployed= in > the Internet. The IETF, as an organization, does not mandate that any > operator anywhere in the world MUST deploy any specific protocol(s). If = you > are aware of the IETF making any such proclamations, then I (and, perhaps= , > others) would certainly welcome any examples you can cite. >=20 > Second, the IETF only has purview to change those standards that it has > created, for example: SNMP, NETCONF/YANG, HTTP(S), data models used > specifically by those protocols, etc. IOW, I believe past precedent has = made > it quite clear that the IETF does not "tell" BBF, OMA, IEEE or any other = SDO: a) > the IETF has created its own modification to the other SDO's protocol/dat= a- > model; or, b) the IETF mandates that the SDO, under its own standards- > process, must make modifications to the other SDO's protocols to do X, Y = or > Z. (In my experience, the IETF may _request_ another SDO make changes > or, much more often, provide clarifications to the IETF about the other S= DO's > protocols, but that's as far as things can and should go). >=20 > To summarize: > 1) The IETF does not mandate an operator deploy IETF standards or any > standard, for that matter. > 2) If the IETF does proceed with forming an LMAP WG, then I believe the > IETF should create or, better yet, re-use protocols that it has ownership > _and_ responsibility to maintain, (cf: SNMP, NETCONF/YANG, HTTP(S), etc.)= . > The benefits should be clear: IETF participants have expertise with the I= ETF's > own protocols/data-models which allows for speed and agility to modify > them to suit new applications/use-cases while not breaking backwards > compatibility, (unless it has a clear reason & consensus to do so). > 3) If individuals in the IETF wish to pursue use of *other* SDO's protoc= ols > and/or data-models, particularly _modifications_ to those protocols, for = one > or more functions in LMAP then that activity must occur within the other > SDO's for similar reasons to what I cited in #2. Further, IMHO, the IETF= should > attempt to stay away from relying too heavily on interoperability with ot= her > SDO's protocols, because of the complexity that this creates when > attempting to extend or enhance IETF-owned/controlled protocols. >=20 > With respect to #3, a compromise I could potentially see is what I think = was > first suggested by Phil. Namely, the LMAP WG could be tasked with coming > up with a protocol-neutral "information model" (refer to: > ) for one, or more, components in t= he > LMAP architecture. Such an "information model" may be the _basis_, i.e.: > high-level guidance, upon which other SDO's use to modify their own > protocols and/or data-models to suit the needs of that SDO's participants= . It > would be ideal if we could come up with a minimal number of informational > models that will comprise a small number of LMAP components/functions, > (i.e.: perhaps *just* the configuration and reporting to/from the MAs), a= nd > stick that in as a milestone in the charter. >=20 > At the end of the day, from the PoV of the IETF, every network operator > *will* have the freedom of choice to use, for example, a) all IETF-specif= ied > protocols/data-models; b) a mixture of IETF-specified protocols/data-mode= ls > *and* other SDO's protocols/data-models; c) all other SDO's protocols/dat= a- > models; or, d) none of the above. IMO, I have a preference for (a) for m= y > network, but do not wish to hold other IETF participants back in any way = from > pursuing, outside the IETF, standardization and/or deployment using optio= ns > (b) through (d) depending on their (network's) needs. >=20 > Regards, >=20 > -shane From shane@castlepoint.net Fri May 31 12:59:39 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02D221F90FD for ; Fri, 31 May 2013 12:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-UrBOMqSkIG for ; Fri, 31 May 2013 12:59:33 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 36D8321F9058 for ; Fri, 31 May 2013 12:59:33 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id B1B91300039 for ; Fri, 31 May 2013 19:59:32 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 3CD4B300028; Fri, 31 May 2013 13:59:31 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Fri, 31 May 2013 13:59:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri May 31 13:59:32 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 51a9012442071919811404 X-DSPAM-Factors: 27, 2013+at, 0.01000, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, to+#+#+#+or, 0.01000, be+#+a, 0.01000, and+#+#+#+the, 0.01000, and+#+#+#+the, 0.01000, MA+to, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, could+#+#+#+of, 0.01000, PM+#+#+#+bs7652, 0.01000, To*STARK+BARBARA, 0.01000, to+#+I, 0.01000, to+#+I, 0.01000, to+#+to, 0.01000, Mime-Version*OS+X, 0.01000, bs7652+#+#+wrote, 0.01000, bs7652+#+#+wrote, 0.01000, and+or, 0.01000, and+or, 0.01000, then+I, 0.01000, then+I, 0.01000, not+be, 0.01000, not+be, 0.01000, with+#+of, 0.01000 Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 19:59:39 -0000 Hi Barbara, On May 31, 2013, at 1:09 PM, "STARK, BARBARA H" wrote: > Hi Shane, > It sounds like we're very close. > Would you agree to the following deliverables? >=20 > > - The LMAP Framework - provides common terminology and justifies the = simplifying constraints > - The LMAP Use Cases - provides the motivating use cases as a basis = for the work > - Information Model, the abstract definition of the information = carried from the Controller to the MA and the information carried from = the MA to the Collector. It includes >=20 > > - the metric(s) that can be measured and > values for its parameters such as the Peer MA participating in the > measurement and the desired environmental conditions (for example, = only > conduct the measurement when there is no user traffic observed) >=20 > > - the schedule: information elements for defining when the = measurement should be run and how > the results should be reported (when and to which Collector) > - the report: information elements for identifying the metric(s) = measured and when, the actual > result, and supporting metadata such as location. Result reports may > be organized in batches or may be reported immediately, such as for = an > on-demand measurement. I'm OK with the above changes. > > - SNMP MIB: Data Model consistent with the Information Model, for = control and reporting using SNMP.=20 > - NETCONF data model: Data Model consistent with the Information = Model, for control and reporting using NETCONF. I'm not OK with deleting deliverables related to protocol selection for: - The Control Protocol and associated data model; and, - The Report Protocol and associated data model. Amongst the potential _IETF_ protocols that could fulfill the needs of = one or the other functions, the IETF should (attempt to) pick one of its = protocols & data-models for each. I would not want to see the LMAP WG = select multiple, overlapping _IETF_ protocols to perform a single = function, (e.g.: we should think long & hard and try to select either = SNMP -or- NETCONF/YANG for the "Control Protocol"). The main benefit = with the above approach is for those who desire, like me, to have a = complete "LMAP solution", with all of the necessary protocols and = data-models, _available_ for them to deploy the IETF LMAP WG will have = produced such. =20 I do not believe this in any way inhibits other SDO's from specifying, = standardizing, recommending, etc. their own protocols for either (or, = both) of the Control or Reporting functions. At the end of the day, the = market (operators) will decide whether they want a wholly IETF solution = or part-IETF/part-other-SDO solution. -shane > And maybe (if people want)... > - IPFIX data model: Data Model consistent with the Information Model, = for reporting using IPFIX. > - REST-style HTTP(s) data model: Data Model consistent with the = Information Model, for reporting using REST-style HTTP(s). >=20 > Barbara >=20 >> -----Original Message----- >> From: Shane Amante [mailto:shane@castlepoint.net] >> Sent: Friday, May 31, 2013 2:29 PM >> To: STARK, BARBARA H >> Cc: Romascanu, Dan (Dan); lmap@ietf.org >> Subject: Re: [lmap] lmap charter - draft 2 >>=20 >> Hi Barbara, >>=20 >> On May 31, 2013, at 9:47 AM, "STARK, BARBARA H" >> wrote: >>>> Ultimately, we can all be more successful if we collectively agree = to >>>> implement a single protocol with a single data-model, >>>=20 >>> It's not going to happen. I will not be party to any such agreement. = I already >> know that I will not be recommending a single protocol for wireless = devices, >> DSL modem/routers, and network elements. I expect to be recommending >> (to my employer) that OMA-DM be used as a control protocol for = wireless >> devices, TR-069 as a control protocol for DSL modems/routers, and = whatever >> the network element vendor implements between their network element >> and their Element Management System (EMS) for network elements. Which >> means I'm not even willing to recommend a single protocol just for = the >> devices and network elements that exist solely within my employer's >> environment. >>>=20 >>> Since some of the network element vendors use SNMP and some are >> wanting to migrate to netconf, I would really prefer for data models = to be >> defined for both of these, rather than for just The Mandatory One = Protocol >> (which may end up being neither of these). Having standard data = models for >> both would be helpful and useful. The effort to do data models for = both >> would probably be less than the effort required to pick one over the = other >> (or pick something different entirely). >>>=20 >>> If you agreed that there could be a different protocol for wireless = devices >> vs. DSL modems/routers (and leave network elements out of it), then I = think >> it might be possible to select a single protocol for each of these. = As long as it's >> the one that wireless providers want for wireless devices and that = DSL >> providers want for DSL devices, and as long as it doesn't have to be = an IETF >> protocol. Otherwise, if the providers' wishes are ignored, history = suggests >> that those providers will completely ignore the recommendation. = Collective >> agreement to implement cannot be assumed to result from IETF = consensus >> to publish. >>> Barbara >>=20 >> I think there's a couple points of disconnect here. First, and = perhaps most >> fundamentally, the IETF only works on protocol and data-model >> specifications and, best current practices that document how a given >> protocol/standard the IETF has specified _has_ been successfully = deployed in >> the Internet. The IETF, as an organization, does not mandate that = any >> operator anywhere in the world MUST deploy any specific protocol(s). = If you >> are aware of the IETF making any such proclamations, then I (and, = perhaps, >> others) would certainly welcome any examples you can cite. >>=20 >> Second, the IETF only has purview to change those standards that it = has >> created, for example: SNMP, NETCONF/YANG, HTTP(S), data models used >> specifically by those protocols, etc. IOW, I believe past precedent = has made >> it quite clear that the IETF does not "tell" BBF, OMA, IEEE or any = other SDO: a) >> the IETF has created its own modification to the other SDO's = protocol/data- >> model; or, b) the IETF mandates that the SDO, under its own = standards- >> process, must make modifications to the other SDO's protocols to do = X, Y or >> Z. (In my experience, the IETF may _request_ another SDO make = changes >> or, much more often, provide clarifications to the IETF about the = other SDO's >> protocols, but that's as far as things can and should go). >>=20 >> To summarize: >> 1) The IETF does not mandate an operator deploy IETF standards or = any >> standard, for that matter. >> 2) If the IETF does proceed with forming an LMAP WG, then I believe = the >> IETF should create or, better yet, re-use protocols that it has = ownership >> _and_ responsibility to maintain, (cf: SNMP, NETCONF/YANG, HTTP(S), = etc.). >> The benefits should be clear: IETF participants have expertise with = the IETF's >> own protocols/data-models which allows for speed and agility to = modify >> them to suit new applications/use-cases while not breaking backwards >> compatibility, (unless it has a clear reason & consensus to do so). >> 3) If individuals in the IETF wish to pursue use of *other* SDO's = protocols >> and/or data-models, particularly _modifications_ to those protocols, = for one >> or more functions in LMAP then that activity must occur within the = other >> SDO's for similar reasons to what I cited in #2. Further, IMHO, the = IETF should >> attempt to stay away from relying too heavily on interoperability = with other >> SDO's protocols, because of the complexity that this creates when >> attempting to extend or enhance IETF-owned/controlled protocols. >>=20 >> With respect to #3, a compromise I could potentially see is what I = think was >> first suggested by Phil. Namely, the LMAP WG could be tasked with = coming >> up with a protocol-neutral "information model" (refer to: >> ) for one, or more, components = in the >> LMAP architecture. Such an "information model" may be the _basis_, = i.e.: >> high-level guidance, upon which other SDO's use to modify their own >> protocols and/or data-models to suit the needs of that SDO's = participants. It >> would be ideal if we could come up with a minimal number of = informational >> models that will comprise a small number of LMAP = components/functions, >> (i.e.: perhaps *just* the configuration and reporting to/from the = MAs), and >> stick that in as a milestone in the charter. >>=20 >> At the end of the day, from the PoV of the IETF, every network = operator >> *will* have the freedom of choice to use, for example, a) all = IETF-specified >> protocols/data-models; b) a mixture of IETF-specified = protocols/data-models >> *and* other SDO's protocols/data-models; c) all other SDO's = protocols/data- >> models; or, d) none of the above. IMO, I have a preference for (a) = for my >> network, but do not wish to hold other IETF participants back in any = way from >> pursuing, outside the IETF, standardization and/or deployment using = options >> (b) through (d) depending on their (network's) needs. >>=20 >> Regards, >>=20 >> -shane >=20 From j.schoenwaelder@jacobs-university.de Fri May 31 13:05:50 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07DE21F947C for ; Fri, 31 May 2013 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpQwlx2vZo0v for ; Fri, 31 May 2013 13:05:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5F821F853A for ; Fri, 31 May 2013 13:05:45 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CDA620BDD; Fri, 31 May 2013 22:05:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3AnlwXc6P4_m; Fri, 31 May 2013 22:05:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A8AE20BD8; Fri, 31 May 2013 22:05:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6D481268E631; Fri, 31 May 2013 22:05:42 +0200 (CEST) Date: Fri, 31 May 2013 22:05:42 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20130531200542.GE65929@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , Shane Amante , "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Shane Amante , "lmap@ietf.org" , "Romascanu, Dan \(Dan\)" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 20:05:51 -0000 Hi, I am against these proposed changes. /js On Fri, May 31, 2013 at 07:09:47PM +0000, STARK, BARBARA H wrote: > Hi Shane, > It sounds like we're very close. > Would you agree to the following deliverables? > > > - The LMAP Framework - provides common terminology and justifies the simplifying constraints > - The LMAP Use Cases - provides the motivating use cases as a basis for the work > - Information Model, the abstract definition of the information carried from the Controller to the MA and the information carried from the MA to the Collector. It includes > > > - the metric(s) that can be measured and > values for its parameters such as the Peer MA participating in the > measurement and the desired environmental conditions (for example, only > conduct the measurement when there is no user traffic observed) > > > - the schedule: information elements for defining when the measurement should be run and how > the results should be reported (when and to which Collector) > - the report: information elements for identifying the metric(s) measured and when, the actual > result, and supporting metadata such as location. Result reports may > be organized in batches or may be reported immediately, such as for an > on-demand measurement. > > > - SNMP MIB: Data Model consistent with the Information Model, for control and reporting using SNMP. > - NETCONF data model: Data Model consistent with the Information Model, for control and reporting using NETCONF. > > And maybe (if people want)... > - IPFIX data model: Data Model consistent with the Information Model, for reporting using IPFIX. > - REST-style HTTP(s) data model: Data Model consistent with the Information Model, for reporting using REST-style HTTP(s). > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bs7652@att.com Fri May 31 14:09:08 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5653321F90CC for ; Fri, 31 May 2013 14:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77cz8Rg96nqY for ; Fri, 31 May 2013 14:09:01 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC9D21F9051 for ; Fri, 31 May 2013 14:09:01 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id d6119a15.5e10e940.420357.00-521.1185930.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 31 May 2013 21:09:01 +0000 (UTC) X-MXL-Hash: 51a9116d61a62628-f5a7b8594a7d16ba225bdedbca9a646050f8f5d1 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id a6119a15.0.420309.00-273.1185781.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 31 May 2013 21:09:00 +0000 (UTC) X-MXL-Hash: 51a9116c08b38ee7-2cf42f2b6d358e38415cd7e283c91e794727c3a1 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4VL8wGg018758; Fri, 31 May 2013 17:08:58 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4VL8kkU018655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 17:08:52 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 31 May 2013 21:08:31 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.02.0342.003; Fri, 31 May 2013 17:08:33 -0400 From: "STARK, BARBARA H" To: Shane Amante Thread-Topic: [lmap] lmap charter - draft 2 Thread-Index: Ac5dQQpm0fx/0vc4R0KsDuJUx0bAUAARytoAAAYmBDAAIsynAAAHK2WAAAFgsQAAB8IRMP//21OAgAA638A= Date: Fri, 31 May 2013 21:08:33 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CC0DA@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.82.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Wdm7nTdX c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=G_PeIll0REcA:10 a=dpDthlLKJOUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=r-i3oeFjtK8A:10 a=rM9AaVUM9HVfpeKUD8MA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=R2D9PS1AeWdT5Vx1:21 a=CkdUOE_d1Yr309dF:21] Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 21:09:08 -0000 > Amongst the potential _IETF_ protocols that could fulfill the needs of on= e or > the other functions, the IETF should (attempt to) pick one of its protoco= ls & > data-models for each. I would not want to see the LMAP WG select multipl= e, > overlapping _IETF_ protocols to perform a single function, (e.g.: we shou= ld > think long & hard and try to select either SNMP -or- NETCONF/YANG for the > "Control Protocol"). The main benefit with the above approach is for tho= se > who desire, like me, to have a complete "LMAP solution", with all of the > necessary protocols and data-models, _available_ for them to deploy the > IETF LMAP WG will have produced such. So you are opposed to LMAP being an agent of providing a useful SNMP MIB fo= r all of the existing network elements (and perhaps cable modems) managed v= ia SNMP?=20 Here's my thought process relative to that... cost of replacing existing network elements whose main purpose is network c= onnectivity just so it can also do some specific metrics; and have corporat= e IT organization add a whole new system to the management network (includi= ng developing interfaces from other OSs) vs.=20 cost of having vendors develop software upgrades for existing network eleme= nts with new, additional management interface with different, unfamiliar pr= otocol to a brand new system that corporate IT would have to add to the man= agement network (including developing OS interfaces) vs.=20 cost of upgrading existing network element's SNMP management interface and = existing management systems To me the math is pretty clear. I know what I would recommend to my employe= r. But if LMAP doesn't want to deliver something useful for the embedded base = of network elements and devices, and only wants to consider greenfield depl= oyments, I don't think that would stop the SNMP MIB from being created some= where else. So if that's where the consensus lies, then I guess if we could get the Inf= ormation Model done first, I would be ok. I'll bother the group no further = after that. Y'all can deliver anything you want, targeted only to those who= desire a complete greenfield "LMAP solution", that has no consideration fo= r re-use/upgrade of anybody's embedded base of devices, network elements, a= nd systems. Barbara From shane@castlepoint.net Fri May 31 14:46:08 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18E321F90CC for ; Fri, 31 May 2013 14:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiRea9Bbnws2 for ; Fri, 31 May 2013 14:46:02 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9234921F8B64 for ; Fri, 31 May 2013 14:46:02 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id C3BE0300080 for ; Fri, 31 May 2013 21:45:39 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id BD12A300062; Fri, 31 May 2013 15:45:38 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302CC0DA@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Fri, 31 May 2013 15:45:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6BCFDF35-14BC-43A9-A795-DF077AFA4A60@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E611302CAF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CB2F6@GAALPA1MSGUSR9L.ITServices.sbc.com> <101DDC16-1C29-4160-8F59-6C10AA4A4508@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBE3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <86D31AC8-9575-4AA1-AC9A-43868F4AD97F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302CBFC9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302CC0DA@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri May 31 15:45:39 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 51a91a0342071302373139 X-DSPAM-Factors: 27, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, IETF+#+to, 0.01000, think+that, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, could+#+#+#+of, 0.01000, PM+#+#+#+bs7652, 0.01000, think+#+would, 0.01000, To*STARK+BARBARA, 0.01000, to+#+to, 0.01000, the+#+#+#+I, 0.01000, I+agree, 0.01000, Mime-Version*OS+X, 0.01000, bs7652+#+#+wrote, 0.01000, then+I, 0.01000, data+#+for, 0.01000, with+#+of, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, a+single, 0.01000, a+single, 0.01000, the+#+#+#+to, 0.01000, them+to, 0.01000, From*Amante+shane, 0.01000, PM+#+BARBARA, 0.01000, of+#+#+#+and, 0.01000 Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap charter - draft 2 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 21:46:08 -0000 Hi Barbara, On May 31, 2013, at 3:08 PM, "STARK, BARBARA H" wrote: >> Amongst the potential _IETF_ protocols that could fulfill the needs = of one or >> the other functions, the IETF should (attempt to) pick one of its = protocols & >> data-models for each. I would not want to see the LMAP WG select = multiple, >> overlapping _IETF_ protocols to perform a single function, (e.g.: we = should >> think long & hard and try to select either SNMP -or- NETCONF/YANG for = the >> "Control Protocol"). The main benefit with the above approach is for = those >> who desire, like me, to have a complete "LMAP solution", with all of = the >> necessary protocols and data-models, _available_ for them to deploy = the >> IETF LMAP WG will have produced such. >=20 > So you are opposed to LMAP being an agent of providing a useful SNMP = MIB for all of the existing network elements (and perhaps cable modems) = managed via SNMP?=20 No. Please re-read my message, above, carefully. I recommended the = IETF _should_, (I did not say: must), try to pick a single IETF protocol = for a particular function. IMO, it is much, much too early -- the LMAP = WG has not even been chartered! -- to declare a single, specific IETF = protocol or data-model as a de-facto winner. This is why I agree with = the present charter when it states, for Control & Reporting transport = protocols: "to be selected, perhaps REST-style HTTP(s) or IPFIX". The = charter is not mandating a choice right now, but it is /eventually/, at = least the way that I'm interpreting it. Yes, it has made some = suggestions, (e.g.: "perhaps"), but I interpret that explanatory and not = declarative. -shane > Here's my thought process relative to that... > cost of replacing existing network elements whose main purpose is = network connectivity just so it can also do some specific metrics; and = have corporate IT organization add a whole new system to the management = network (including developing interfaces from other OSs) > vs.=20 > cost of having vendors develop software upgrades for existing network = elements with new, additional management interface with different, = unfamiliar protocol to a brand new system that corporate IT would have = to add to the management network (including developing OS interfaces) > vs.=20 > cost of upgrading existing network element's SNMP management interface = and existing management systems > To me the math is pretty clear. I know what I would recommend to my = employer. > But if LMAP doesn't want to deliver something useful for the embedded = base of network elements and devices, and only wants to consider = greenfield deployments, I don't think that would stop the SNMP MIB from = being created somewhere else. > So if that's where the consensus lies, then I guess if we could get = the Information Model done first, I would be ok. I'll bother the group = no further after that. Y'all can deliver anything you want, targeted = only to those who desire a complete greenfield "LMAP solution", that has = no consideration for re-use/upgrade of anybody's embedded base of = devices, network elements, and systems. > Barbara