[ippm] IPPM Metric Registry Concept of Roles

Heitor Ganzeli <heitor@nic.br> Tue, 29 January 2019 17:37 UTC

Return-Path: <heitor@nic.br>
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 88655130E9C for <ippm@ietfa.amsl.com>; Tue, 29 Jan 2019 09:37:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.29
X-Spam-Level:
X-Spam-Status: No, score=-4.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E56AHBTXhFpJ for <ippm@ietfa.amsl.com>; Tue, 29 Jan 2019 09:37:09 -0800 (PST)
Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14533130E66 for <ippm@ietf.org>; Tue, 29 Jan 2019 09:37:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 1E1D918E110; Tue, 29 Jan 2019 15:37:07 -0200 (-02)
Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmpOrFQjA1jM; Tue, 29 Jan 2019 15:37:07 -0200 (-02)
Received: from [IPv6:2001:12ff:0:5::138] (unknown [IPv6:2001:12ff:0:5::138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: heitor@nic.br) by mail.nic.br (Postfix) with ESMTPSA id C7DF618E10E; Tue, 29 Jan 2019 15:37:06 -0200 (-02)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1548783426; bh=6pXVo9DR624G5M90wxiBeOhJ97qMRfLB12Zt9jyIPj0=; h=To:Subject:From:Date:From; b=SkW4PGfgOrve6PTnFBjTRT+hhMULMX2YYtPX6mjcAt4wQ57kXtka2KLh01zJlzSTG 2lFxEGl2akAygn/Loqt6OPA2NP0gmEN7FJNHwSl5KfksMLsmA5xLCluabPzEDai1S4 u23xDgcrADVXdZ5RDhmL+XpMlIwbysI/gIGuX2JA=
To: ippm@ietf.org
From: Heitor Ganzeli <heitor@nic.br>
Openpgp: preference=signencrypt
Autocrypt: addr=heitor@nic.br; prefer-encrypt=mutual; keydata= mQINBFjubQ8BEAC/3D7yUlpaJizgcNBUinaaEzS02HUgJjsPpFcOhsl9uIfutd/yN9MVdniG FZgiJ2xhptJyLXNiGZgtMEdj5J/1zzQFZPp1pF5ZlVqxjNs1NFqgC+0pVC0qdnxOY5fgfRVj obsdBTmVvqOAZ1QGhkLjjvoWcBS2x0owWwKNICKlNxIMwK2GfPMgwntaf7RFPcUr44kJFnNA xYADu3AdBHGAanpXfCrtcO5aIIPVydxKGIgHKufQczqxBfCmMHL+NwK/doqkUTsUmRysr1ok TPrEjFej6DthZOCVAHYr2t+/EhY3c8sqdBEXSg9LQQpcENVd9UeZYiy4tIEzEF2fEgJi88Yi ADC43V0wNqVgSmSeUgMNTtEVPm4oF/im63/MZWvVWX9yBFM+1648PSuoWI293hnUwRolB++Y eo1T52MvDxDAB5d2MfPHOdOBbZYXcCbBQGk7WnzGkSTf/V6Kk3DWexjewQxwpcd3ldXyQ73/ 4zBGymHzwiX6gh43Oj1xNpmMGQqdLE7nQYjGi9sPV7Qj+wU4YGkagDPbU2TJc2wn8rwKT/EE RnImjrdtTndOFXA4yBbklMKa1YRV1dUWswVvTemiVSIhknRq3pcJTcA9CwFxurTei69Spwy9 B0sfzWoXLXWawComQwlpoaDtLzicc8Wyz6kx7TRoSTgBSN3HhQARAQABtCdIZWl0b3IgZGUg U291emEgR2FuemVsaSA8aGVpdG9yQG5pYy5icj6JAj0EEwEKACcFAljubQ8CGwMFCQeGH4AF CwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQSps6diIRt07HZxAAqOgYAB+mipk7Uuk6I6EX RPuj2R8ajAPaLKuzQSRIldwgM8bAmfKU9ng5NYRqbe169HIVNnQRatHYoIZZYUxaMt64cGoh Y4LvKJqRvyAHoYrgmKVD2Qn6xH5mqoj45UNTZlcvtVYVe8hFua7L433DP43vA9e/pf6H6s6l 4xyoGLtinE4+xem6LcXL0RmCtWQllP2qhecpykhPuzOj7uxXu0gR4juZSQIz2yaWg/nuwk23 uclLhTY6vdIrCu+PCmBXOiD4qw22lsElLt2C81Tqw+ceY+rNsuJHzqdxT02DKjOErnrMfVNj RTy++b+EtqkwiAYGyPMny7zATRF08RHSwjX6efUfbP1OIzURHuEOXzLj0nDLiZmCwxSlBJbL cOBkikFCRx7ppEPmnrsCRYMpS+x+V0Kw6bmDu3ZH9XVIpvDzzKYNk0C5jjkeg0SoGWZnLqDr w+ZkBLPBcaegt/s5ImWmTFSeFVera+OvUGjllJa1rmoucAhv6YiAq7JudFA29be0hkyo9Ynf ESUfaRc7fcjFJQOl3r+Ts3f4DK6sUnOBXzgARzbl2A0gfwJUMXa8ulfyFK2fdAijSwWKhvux dF62hv8c1nsEXXXLI5rOHwMHF3BqISYkSFPx+014FC23zBoPma50Xfi6dLFNSZ9xYveF4VzW P4ff9Y8TLJofGuq5Ag0EWO5tDwEQAL5KEBkXrH1cWXwfRxo1disK7iotCCsrMEa9rqT6uYvm 4jFo+rg0Y0TdpbCdL2GcGgU2BOWrAg7VvcknrPNVfeaW8dXCAvr1x5+qRzs3XyH+RSyWvHTd rRD9dZOmXML7pJk+SHgNOVnTNsH65l4QeFFTPseoNCq7RWl92URlqcyZI44f1aTCcpxSkWCp L3f/G6byOZH82/nO/1BS4JwwwQKTYyD8Q015g86eGnMAxqt3qtlMVvU3vw+YHmJWAav7cV9i AhEXo1nsnQz4SU6UXfbh8lP0FdFJLEUCrdbFFIGI4vLvWiLDEJmYqDsiH6JmR0MY8oFCHjds w0uiP4jsDLt5554OdnVKdYft8FnPLdn8OghiIM/gNYrdTjFZXmA1dUS/odK+RwCCqE5avqMU d8G93ZdlcWPGgwZXNuthAPHNiroaQOkeuq72oX9m2213xqhKFc3R2psgSomY30zraVmm+tw8 GnIhKxBl/1Ky8tFG0y5Qfd7LY84giXoVWCbn0rPZnzgSGziqlSehlif8gi40YahfQdu31H2Q F0z3NMvFXx2tibE071t1Fg3Evnsl9O+KoKdLs9+2Sw/fP31bIi4sHjp5ChuXeeXRY7LtMRfU KGAGrLkoEcQZiprAC3Be3TOWP0892tMpsdC58uud/5TG01Pcq63KkXiVSyW9ouBHABEBAAGJ AiUEGAEKAA8FAljubQ8CGwwFCQeGH4AACgkQSps6diIRt05GoRAAptasEtPpjO2hYL8lfggT MlanCi5q1o9ifjx76hqNvoxJuhmEBVZv06GrPJ5n8angF5OoCpbDPEDl8umyDr6xVS0IJ/8q 0CDrJOadYf4wXdFuavi332zfBvqtrpmBVUPjSdoBhNzrzpbz9rF3vUgAEWIoHEeL+mYtXhks vb14qZ2VJ3l/h5oxxdeTj5WnP+w4buUrDq38zVEyNT9Hds7wpmnKa2Nr/xmCmz+04im/6y/A BJ2q5VD7pQmayfIkgm5JigCwE94wuruC/bBKeHX3GlhgWGUmp76vllP71oodw3FJ2csnydSq ITk9yC14s0Ylp8wpOP1nWqxPPpLD7PX5JCoSgjyk4JvhHj6Qqb3f0ZjxKC1/mNoV+RUWQ3AM 6IINQ6t/JZ8FmsQKcckwZ+VLL68ynQJSC3bq713j5r4zZxCzFK2ljUYCPEM4hkitdBQfTqS6 KQg5bXAASZ07GwTDPVjoR8U9Rf++lkCR4Gcdc9RXXS6bIGKSgiL0JyWvRF8axDxlB/AOI28f yml0IH5r7WNMGaALbfVIckclmxfdwn6/RHW6e25WohiIVTBcWIRGmRBYWqkLpcQK/v/nWF9i Hdu3mLmipVu5uzDuKZrLUDExvquK/6T+Ra8wLVGSE5rmBYOrkSD0WCRXO+oYc4bSrgmAhb7G +TCfjtB1F8rNW6U=
Message-ID: <2ee89f4a-b4c2-c9fe-2f4f-a9172891d9a8@nic.br>
Date: Tue, 29 Jan 2019 15:37:06 -0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------4341717550C23625132DAA1B"
Content-Language: en-US
DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br C7DF618E10E
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/9XCbjTFJWTt_nRwEwP_vEDibh_I>
Subject: [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: Tue, 29 Jan 2019 17:38:16 -0000

**

*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-3537R.: 4077
INOC 22548*HSG
www.nic.br <http://nic.br>