Re: [OPSAWG] Feedback on draft-www-opsawg-yang-vpn-service-pm

Thanks Med for clarification, we discussed the downside of using average before, i.e., hide outlier, which is more appropriate for relative even distribution.
That is why we introduce percentiles. 3 percentiles value can be 50 percentile,75 percentile,95 percentile which is configured by setting low-percentile,middle-percentile, high-percentile under nt:link
     augment /nw:networks/nw:network/nt:link:
       +--rw low-percentile                    percentile
       +--rw high-percentile                   percentile
       +--rw middle-percentile                 percentile
Then high-delay-percentile, high-jitter-percentile, etc can be used to report the measured delay value, jitter value corresponding to specific percentile value, i.e., high-percentile, low-percentile, middle-percentile.
As Med clarified we have defined default value for them.
Regarding the counter, I tend to agree, in addition, I think counter32 is sufficient for discard, error, unknown protocol related statistics, which is similar to
What is defined in ietf-interfaces.

-Qin
-----邮件原件-----
发件人: OPSAWG [mailto:opsawg-bounces@ietf.org] 代表 mohamed.boucadair@orange.com
发送时间: 2020年12月14日 22:58
收件人: Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org>; opsawg <opsawg@ietf.org>
主题: Re: [OPSAWG] Feedback on draft-www-opsawg-yang-vpn-service-pm

Hi Joe, all, 

Thank you for sharing these comments.

Instead of sharing avg values, we do think that sharing percentile values is more useful. Up to 3 sets of percentiles can be shared for each performance metric: low (e.g., 5.00), mid (50.00), or high (90.00). The exact percentile value to characterize low/mid/high is configurable. Otherwise, default values will be used (will update the module + explain the behavior in the text).    

If all *-percentile parameters are set to 0.00, this means that no percentile-related nodes will be reported for a given performance metric (one-way delay, one-way delay variation). Only peak/min/current values can be reported.

Fully agree with your comment on the counters.

More text will be added to describe the intended behavior. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:opsawg-bounces@ietf.org] De la part de Joe Clarke 
> (jclarke) Envoyé : vendredi 11 décembre 2020 21:28 À : opsawg 
> <opsawg@ietf.org> Objet : [OPSAWG] Feedback on 
> draft-www-opsawg-yang-vpn-service-pm
> 
> During the IETF109 opsawg session, this draft was presented, and I was 
> concerned that a lot of its work had happened amongst the authors of 
> the L2NM/L3NM et al work.  I hadn’t seen a lot of discussion on this 
> list.
> 
> I wanted to kick off some discussion around it.
> 
> As contributor:
> 
> I think this work is useful and complements the VPN NM work nicely.
> I had a few questions/comments as I read the -02 version of this 
> draft.  First, the percentile leafs use the word “percentile” to 
> define what it is.  I think some more wording around what is meant by 
> the low/middle/high percentiles would be useful.  One can piece this 
> together by reading through the YANG module, but I would like to see 
> some explanatory text in the body of the document that explains the 
> percentile breakdowns.  Examples of this would also be helpful.
> 
> What would happen if you set all percentile leafs to 0.00?  Would that 
> only affect the delay and jitter leafs?  Again, I think some 
> clarifying text is needed here as to how to use these data points.
> 
> I’m also curious about some of the tp-telemetry-attributes counters.
> Why are the octets, unicast, and nunicast counters 32-bit?  I think 
> they should be 64-bit to be in line with ietf-interfaces.  And for all 
> of these leafs, why are they uint instead of counter?  They seem to be 
> counters in reading the descriptions.  The same counter questions 
> applies to those -count leafs under loss-statistics.
> 
> Joe
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg