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

gregory.mirsky@ztetx.com Mon, 14 December 2020 20:32 UTC

Return-Path: <gregory.mirsky@ztetx.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCD03A1C18 for <opsawg@ietfa.amsl.com>; Mon, 14 Dec 2020 12:32:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.008
X-Spam-Level:
X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SHARE_50_50=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbFgu7hyOD7C for <opsawg@ietfa.amsl.com>; Mon, 14 Dec 2020 12:32:34 -0800 (PST)
Received: from mxus.zteusa.com (mxus.zteusa.com [4.14.134.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DAD3A1C15 for <opsawg@ietf.org>; Mon, 14 Dec 2020 12:32:34 -0800 (PST)
Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id DAA33C7B9093BE611695; Tue, 15 Dec 2020 04:32:33 +0800 (CST)
Received: from mgapp01.zte.com.cn ([10.36.9.142]) by mse-us.zte.com.cn with SMTP id 0BEKWSEI011513; Tue, 15 Dec 2020 04:32:28 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com)
Received: from mapi (mgapp01[null]) by mapi (Zmail) with MAPI id mid81; Tue, 15 Dec 2020 04:32:28 +0800 (CST)
Date: Tue, 15 Dec 2020 04:32:28 +0800
X-Zmail-TransId: 2af95fd7cbdcfda4fb8f
X-Mailer: Zmail v1.0
Message-ID: <202012150432285733734@zte.com.cn>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAADC2AACC@dggeml511-mbs.china.huawei.com>
References: B8F9A780D330094D99AF023C5877DABAADC2AACC@dggeml511-mbs.china.huawei.com
Mime-Version: 1.0
From: gregory.mirsky@ztetx.com
To: bill.wu@huawei.com
Cc: mohamed.boucadair@orange.com, jclarke=40cisco.com@dmarc.ietf.org, opsawg@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-us.zte.com.cn 0BEKWSEI011513
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/2KW5u3nI7OAYU_fSzkcZMh1VXlw>
Subject: Re: [OPSAWG] Feedback on draft-www-opsawg-yang-vpn-service-pm
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Dec 2020 20:32:37 -0000

Hi Qin,


thank you for the detailed analysis of advantages of using percentiles compared with an average metric. I've noticed that in the draft the percentile is defined as 

 typedef percentile {
 type decimal64 {
 fraction-digits 2;
 }
 description
 "The nth percentile of a set of data is the
 value at which n percent of the data is below it.";
 }
Doesn't that limit the ability of request the reported percentile, e.g., five 9s? I can reference the STAMP YANG data model where:

 typedef percentile {
 type decimal64 {
 fraction-digits 5;
 }
 description
 "Percentile is a measure used in statistics
 indicating the value below which a given
 percentage of observations in a group of
 observations fall.";
 }






Regards,


Greg Mirsky






Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division









E: gregory.mirsky@ztetx.com 
www.zte.com.cn






Original Mail



Sender: QinWu
To: mohamed.boucadair@orange.com;Joe Clarke (jclarke);opsawg;
Date: 2020/12/14 07:33
Subject: 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
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg