Re: [ippm] IPPM Metric Registry Concept of Roles

[Heitor Ganzeli <[e-mail]>]

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 onemeasurement
agent that generates the packets and another agent thatreceives 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 itis 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
suppliedfor 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:[e-mail]] *On Behalf Of *Heitor Ganzeli
> *Sent:* Tuesday, January 29, 2019 12:37 PM
> *To:* [e-mail]
> *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)
> [phone] 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)
[phone]R.: 4077
INOC 22548*HSG
www.nic.br <http://nic.br>