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

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 11 Dec 2020 20:28:08 +0000

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

---

From: <[email-masked]>
Date: Mon, 14 Dec 2020 14:58:08 +0000

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:[email-masked]] De la part de Joe
> Clarke (jclarke)
> Envoyé : vendredi 11 décembre 2020 21:28
> À : opsawg <[email-masked]>
> 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 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
> [email-masked]
> 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.