Re: [ippm] IPPM Metric Registry Concept of Roles

[Heitor Ganzeli <[e-mail]>]

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

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


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:[e-mail]]
> *Sent:* Wednesday, January 30, 2019 11:43 AM
> *To:* MORTON, ALFRED C (AL) <[e-mail]>; [e-mail]
> *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:[e-mail]] *On Behalf Of *Heitor
>     Ganzeli
>     *Sent:* Tuesday, January 29, 2019 12:37 PM
>     *To:* [e-mail] <mailto:[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
> <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)
[phone]R.: 4077
INOC 22548*HSG
www.nic.br <http://nic.br>