Re: [ippm] IPPM Metric Registry Concept of Roles
"MORTON, ALFRED C (AL)" <acm@research.att.com> Thu, 31 January 2019 19:06 UTC
Return-Path: <acm@research.att.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE72130E78 for <ippm@ietfa.amsl.com>; Thu, 31 Jan 2019 11:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.399
X-Spam-Level: *
X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QscQyXK7MozT for <ippm@ietfa.amsl.com>; Thu, 31 Jan 2019 11:06:48 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447D4130E6A for <ippm@ietf.org>; Thu, 31 Jan 2019 11:06:48 -0800 (PST)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x0VIuMEG046459; Thu, 31 Jan 2019 14:06:47 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049287.ppops.net-00191d01. with ESMTP id 2qc6bp925u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Jan 2019 14:06:45 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x0VJ4qjA023660; Thu, 31 Jan 2019 13:04:53 -0600
Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [135.46.181.149]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x0VJ4nDb023582; Thu, 31 Jan 2019 13:04:49 -0600
Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [127.0.0.1]) by zlp30499.vci.att.com (Service) with ESMTP id 7E7614013B32; Thu, 31 Jan 2019 19:04:49 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30499.vci.att.com (Service) with ESMTP id 3F28E4013B30; Thu, 31 Jan 2019 19:04:49 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x0VJ4nff004460; Thu, 31 Jan 2019 13:04:49 -0600
Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x0VJ4fXS004067; Thu, 31 Jan 2019 13:04:42 -0600
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id 04465E1041; Thu, 31 Jan 2019 14:04:41 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0435.000; Thu, 31 Jan 2019 14:03:26 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Heitor Ganzeli <heitor@nic.br>, "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: [ippm] IPPM Metric Registry Concept of Roles
Thread-Index: AQHUt/lXmRRjLh12ukeh0jjkx4wxUKXH2uXAgAB+pgCAAQz8QIAApgwA//+w9SA=
Date: Thu, 31 Jan 2019 19:03:25 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF6BFD389D@njmtexg5.research.att.com>
References: <2ee89f4a-b4c2-c9fe-2f4f-a9172891d9a8@nic.br> <4D7F4AD313D3FC43A053B309F97543CF6BFD2DB8@njmtexg5.research.att.com> <0f6adc59-66f6-9ea0-2cba-475e99c3ff91@nic.br> <4D7F4AD313D3FC43A053B309F97543CF6BFD36B4@njmtexg5.research.att.com> <b4e9c4c3-3939-53c0-903e-75ab66fa1980@nic.br>
In-Reply-To: <b4e9c4c3-3939-53c0-903e-75ab66fa1980@nic.br>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [69.141.203.172]
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF6BFD389Dnjmtexg5researc_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-31_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901310141
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/mYFZTXxeL7Uz7hyNGjeFb0tcASk>
Subject: Re: [ippm] IPPM Metric Registry Concept of Roles
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2019 19:06:51 -0000
Great, thanks for the reference to the LMAP YANG model. I think we should say: It should be noted that the LMAP framework [RFC7594] distinguishes the Role from other Run-time Parameters by defining a special parameter "Roles" inside the Registry-grouping Function list in the LMAP YANG Model [RFC8194]. Al From: Heitor Ganzeli [mailto:heitor@nic.br] Sent: Thursday, January 31, 2019 1:40 PM To: MORTON, ALFRED C (AL) <acm@research.att.com>; ippm@ietf.org Subject: Re: [ippm] IPPM Metric Registry Concept of Roles Hi Al, The term "Function" is actually from rfc8194 - YANG Data Model for LMAP section 4.1 page 17. https://tools.ietf.org/html/rfc8194#page-17<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8194-23page-2D17&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=6p5VASQ5wD7b0yR1P86X7L9DD1DznoTcc0ObrTF4sls&s=y8rhttmoB7Dsk9KdYI-OwaDSRJPIO12eNpXC29Lpi8Y&e=> We didn't know how to concisely reference the object and put only "Function list". However, RFC7594 uses the term "Measurement Method role" which is first mentioned in section 3. https://tools.ietf.org/html/rfc7594#section-3<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7594-23section-2D3&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=6p5VASQ5wD7b0yR1P86X7L9DD1DznoTcc0ObrTF4sls&s=UoSTqfBW5u5tD9fGN05CbjNoOXiMz6N7c4MTMCBfrWs&e=> Thanks again for considering our requests, Regards, On 1/31/19 11:51 AM, MORTON, ALFRED C (AL) wrote: Hi Heitor, I agree that we can add text referencing the LMAP Framework RFC 7594, since we introduced that reference already in the early sections. So the last paragraph would read: When the Role column of a registry entry defines more than one Role, then the Role SHALL be treated as a Run-time Parameter and supplied for execution. It should be noted that the LMAP framework [RFC7594] distinguishes the Role from other Run-time Parameters by defining a special parameter "Roles" inside the Function list. -=-=-=-=-=-=-=-=-=-=-=- I found that the term “role” is used consistently with the definition in the Registry draft throughout, so no need to provide a Section number in the reference to RFC 7594. However, the term “Function List” that you proposed to end the new sentence does not appear in RFC 7594. Can you supply the term that RFC 7594 uses, and a section reference, please? thanks again, Al From: Heitor Ganzeli [mailto:heitor@nic.br] Sent: Wednesday, January 30, 2019 11:43 AM To: MORTON, ALFRED C (AL) <acm@research.att.com><mailto:acm@research.att.com>; ippm@ietf.org<mailto:ippm@ietf.org> Subject: Re: [ippm] IPPM Metric Registry Concept of Roles Hi Al, Thanks for your reply. Discussing the new text internally, we think it still gives margin for multiple interpretations mainly because Roles should be informed inside the "Function" list on the LMAP framework, instead of "parameters" like other run-time parameters. We don't know if framework specificities can be mentioned here, but we'd like to suggest the following modifications: -=-=-=-=-=-=-=-=- 7.3.6 Role In some methods of measurement, there may be several roles defined, e.g., for a one-way packet delay active measurement there is one measurement agent that generates the packets and another agent that receives the packets. This column contains the name of the role(s) for this particular entry. In the one-way delay example above, there should be two entries in the Role registry column, "Source" and "Destination". When a measurement agent is instructed to perform the "Source" Role for one-way delay metric, the agent knows that it is required to generate packets. When the Role column of a registry entry defines more than one Role, then the Role SHALL be treated as a Run-time Parameter, and supplied for execution. It should be noted that the LMAP framework distinguishes Role from other Run-time Parameters by defining a special parameter "Roles" inside the Function list. -=-=-=-=-=-=-=-=- Regards, On 1/30/19 12:20 PM, MORTON, ALFRED C (AL) wrote: Hi Heitor, Thanks for your e-mail and your careful read of the Registry draft. It’s good to hear that you are developing an LMAP-based system. I think you’ve discovered a case where we failed to keep the Role description and the current thinking in-sync. I certainly never meant for 2 roles to result in two separate registry entries, but that’s what the description says in -17. When reading this paragraph, I saw many places where I think we can clarify the text. I propose the following revised section which follows our shared understanding. thanks again, and regards, Al -=-=-=-=-=-=-=-=- 7.3.6 Role In some methods of measurement, there may be several roles defined, e.g., for a one-way packet delay active measurement there is one measurement agent that generates the packets and another agent that receives the packets. This column contains the name of the role(s) for this particular entry. In the one-way delay example above, there should be two entries in the Role registry column, one for each Role. When a measurement agent is instructed to perform the "Source" Role for one-way delay metric, the agent knows that it is required to generate packets. The values for this field are defined in the reference method of measurement (and this frequently results in abbreviated role names such as "Src"). When the Role column of a registry entry defines more than one Role, then the Role SHALL be treated as a Run-time Parameter and supplied for execution. -=-=-=-=-=-=-=-=- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Heitor Ganzeli Sent: Tuesday, January 29, 2019 12:37 PM To: ippm@ietf.org<mailto:ippm@ietf.org> Subject: [ippm] IPPM Metric Registry Concept of Roles Hello IPPM WG. At NIC.br we are developing a measurement system based on the LMAP framework. Metrics (mainly private ones) are defined following the proposed IPPM metric registry standard. During this effort we identified some doubts regarding the concept of roles in the metric registry: draft-ietf-ippm-metric-registry-17 states at 7.3.6 “7.3.6. Role In some method of measurements, there may be several roles defined e.g. on a one-way packet delay active measurement, there is one measurement agent that generates the packets and the other one that receives the packets. This column contains the name of the role for this particular entry. In the previous example, there should be two entries in the registry, one for each role, so that when a measurement agent is instructed to perform the one way delay source metric know that it is supposed to generate packets. The values for this field are defined in the reference method of measurement.” Regarding a) an interest to avoid proliferation of metrics and b) efficient use of the LMAP Framework (announcement of capabilities, scheduling of tasks and reporting of results), shouldn't it be enough and preferred to keep a single metric definition that can be referenced with one of multiple possible roles? For example, an LMAP measurement agent could announce the capability to execute a task producing the OWPD metric, acting either as a client or a server. When scheduling a task the LMAP controller would reference that OWPD metric and pin the role to a specific value (ex: client). And when reporting measurement results that same role would be reported together with the metric URN. It seems the above use cases are solved with a single metric that allows multiple roles. Regarding the metric registry, this perspective interprets the "role" column as a enumeration of all roles applicable to this metric, instead of indicating a single mandatory role. Reinforcing this point of view, the draft-ietf-ippm-initial-registry-09 seem to list all possible roles when describing metrics. Items 4.3.6, 6.3.6, 7.3.6, 8.3.6, 9.3.6. But we do not have any concrete reference on how the final LMAP report would be when reporting data for these metrics. Could you please comment on the real motivation behind the current draft's choice of creating multiple similar metrics with a single role each? and if this part of the draft is open for discussions and improvements? Thanks in advance, -- [NIC.br |]Heitor Ganzeli Analista de Projetos/Projects Analyst Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.: 4077 INOC 22548*HSG www.nic.br<https://urldefense.proofpoint.com/v2/url?u=http-3A__nic.br&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=-SdzhkV5T1JPu4CVfVSzHFx2EMN32n-y7kdUY0INPbs&s=tMrmlKjleks6aqNR_e2hHWBgD41F6PtgBcIUUyRXUFM&e=> -- [NIC.br |]Heitor Ganzeli Analista de Projetos/Projects Analyst Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.: 4077 INOC 22548*HSG www.nic.br<https://urldefense.proofpoint.com/v2/url?u=http-3A__nic.br&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=fG1ocUH95zQ-PzyYzaD--CzygSO2jA_RSUpES0wjDpo&s=MUCJBAT5t4EXSTjulqkhUKD6YwHRvVfOx0yzhS2FGfc&e=> -- [NIC.br |]Heitor Ganzeli Analista de Projetos/Projects Analyst Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.: 4077 INOC 22548*HSG www.nic.br<https://urldefense.proofpoint.com/v2/url?u=http-3A__nic.br&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=6p5VASQ5wD7b0yR1P86X7L9DD1DznoTcc0ObrTF4sls&s=QOPZTCihknPSVf5ZFftCv9_ay06SEk8rjmb3st5mkAk&e=>
- [ippm] IPPM Metric Registry Concept of Roles Heitor Ganzeli
- Re: [ippm] IPPM Metric Registry Concept of Roles MORTON, ALFRED C (AL)
- Re: [ippm] IPPM Metric Registry Concept of Roles Heitor Ganzeli
- Re: [ippm] IPPM Metric Registry Concept of Roles MORTON, ALFRED C (AL)
- Re: [ippm] IPPM Metric Registry Concept of Roles Heitor Ganzeli
- Re: [ippm] IPPM Metric Registry Concept of Roles MORTON, ALFRED C (AL)
- Re: [ippm] IPPM Metric Registry Concept of Roles Heitor Ganzeli
- Re: [ippm] IPPM Metric Registry Concept of Roles MORTON, ALFRED C (AL)
- Re: [ippm] IPPM Metric Registry Concept of Roles Heitor Ganzeli