Re: [ippm] IPPM Metric Registry Concept of Roles

[Heitor Ganzeli <[e-mail]>]

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]>; [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 <http://nic.br>