Re: [ippm] IPPM Metric Registry Concept of Roles

[Heitor Ganzeli <[e-mail]>]

Thanks! I'm sure the team will be thrilled to share our findings once we
get more concrete results from the system.

Regards,

On 1/31/19 6:29 PM, MORTON, ALFRED C (AL) wrote:
>
> Great!  I think I speak for all of us who have worked
>
> on the Performance Metrics Registry and/or LMAP when I
>
> say that IPPM would like to hear about your measurement
>
> system development at NIC.br (when you’re ready), on
>
> the list and possibly at a meeting.
>
>  
>
> thanks again for your review!
>
> Al  
>
>  
>
> *From:*Heitor Ganzeli [mailto:[e-mail]]
> *Sent:* Thursday, January 31, 2019 3:19 PM
> *To:* MORTON, ALFRED C (AL) <[e-mail]>; [e-mail]
> *Subject:* Re: [ippm] IPPM Metric Registry Concept of Roles
>
>  
>
> Ok, thanks a lot! I think that closes all our doubts regarding the matter.
>
>  
>
> Regards,
>
> On 1/31/19 5:03 PM, MORTON, ALFRED C (AL) wrote:
>
>     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:[e-mail]]
>     *Sent:* Thursday, January 31, 2019 1:40 PM
>     *To:* MORTON, ALFRED C (AL) <[e-mail]>
>     <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>     *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:[e-mail]]
>         *Sent:* Wednesday, January 30, 2019 11:43 AM
>         *To:* MORTON, ALFRED C (AL) <[e-mail]>
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[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
>     <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=>
>
>
> -- 
> 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=2hGiiEpJIC8A3jaYmWr17H1ypQeFeDJoYmo4VksLzdQ&s=j9NRs3Qg01ScMMrjZYHfzNfkNQC71N2aMey4K8O81ZU&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>