Re: [ippm] [Teas] STAMP YANG model
Leeyoung <leeyoung@huawei.com> Thu, 19 July 2018 14:38 UTC
Return-Path: <leeyoung@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7D21310F3; Thu, 19 Jul 2018 07:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.101
X-Spam-Level: ***
X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 4nVEwZF9h3hG; Thu, 19 Jul 2018 07:38:32 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F08E8130F4A; Thu, 19 Jul 2018 07:38:31 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8AB34528F1E53; Thu, 19 Jul 2018 15:38:28 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 19 Jul 2018 15:38:29 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.107]) by SJCEML701-CHM.china.huawei.com ([169.254.3.200]) with mapi id 14.03.0399.000; Thu, 19 Jul 2018 07:38:25 -0700
From: Leeyoung <leeyoung@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, TEAS WG <teas@ietf.org>
CC: IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [Teas] STAMP YANG model
Thread-Index: AQHUHq3N91c+saoAVEy+NoeU6/xIyKSWlKgQ
Date: Thu, 19 Jul 2018 14:38:24 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173D03D892@sjceml521-mbx.china.huawei.com>
References: <CA+RyBmUO+xPXZOMJSj3tDdFrTu-suLpBPRo1oc8BYwRGeuhnRA@mail.gmail.com>
In-Reply-To: <CA+RyBmUO+xPXZOMJSj3tDdFrTu-suLpBPRo1oc8BYwRGeuhnRA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.128.37]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E173D03D892sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/I8syjbusqauxS5dCwvWiZaeD98Q>
Subject: Re: [ippm] [Teas] STAMP YANG model
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2018 14:38:44 -0000
Hi Greg, Thanks for the pointer. It looks to me that your model does not have all the PM data we are augmenting from ietf-te-types in which the grouping for performance-metric-attributes are defined based on RFC7471/7810/7823. Please find “grouping performance-metric-attributes: from https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/?include_text=1 (see also the below excerpt) to see what is defined. I have three points to address: · The data your model does not have bandwidth and utilization aspect. These are TE specific data which is of our interest. · In regards to delay and loss, there is some overlap between your model and what is defined in grouping performance-metric-attributes, but you have delay and loss related data in much more detail (e.g. low/high percentile, far end/near end delay, loss-burst-max/min/count, etc.) These details are not needed in our case. · In regards to bi-directional PM data which is not covered by the current ietf-te-types, but based on the off-line conversation with Rakesh/Pavan, there is a plan to add bi-directional aspects of PM attributes to ietf-te-type module. My recommendation is this: · One option: you re-use the overlapping data from the grouping from ietf-te-types (assuming it will update with bi-directional PM data) and define your specific data in your module. · Other option: you create an independent PM type module and define groupings so that other can import and re-uses it. If you can join weekly YANG design team meeting (I will ask Tarek/Xufeng to forward YANG weekly meeting information), that will be the best to discuss this issue. Thanks, Young ------------------excerpt from iert-te-types--------------------------------------------- grouping performance-metric-attributes { description "Link performance information in real time."; reference "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. RFC7810: IS-IS Traffic Engineering (TE) Metric Extensions. RFC7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; leaf unidirectional-delay { type uint32 { range 0..16777215; } description "Delay or latency in micro seconds."; } leaf unidirectional-min-delay { type uint32 { range 0..16777215; } description "Minimum delay or latency in micro seconds."; } leaf unidirectional-max-delay { type uint32 { range 0..16777215; } description "Maximum delay or latency in micro seconds."; } leaf unidirectional-delay-variation { type uint32 { range 0..16777215; } description "Delay variation in micro seconds."; } leaf unidirectional-packet-loss { type decimal64 { fraction-digits 6; range "0 .. 50.331642"; Saad, et al. Expires January 2, 2019 [Page 91] Internet-Draft TE YANG Data Model July 2018 } description "Packet loss as a percentage of the total traffic sent over a configurable interval. The finest precision is 0.000003%."; } leaf unidirectional-residual-bandwidth { type rt-types:bandwidth-ieee-float32; description "Residual bandwidth that subtracts tunnel reservations from Maximum Bandwidth (or link capacity) [RFC3630] and provides an aggregated remainder across QoS classes."; } leaf unidirectional-available-bandwidth { type rt-types:bandwidth-ieee-float32; description "Available bandwidth that is defined to be residual bandwidth minus the measured bandwidth used for the actual forwarding of non-RSVP-TE LSP packets. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths."; } leaf unidirectional-utilized-bandwidth { type rt-types:bandwidth-ieee-float32; description "Bandwidth utilization that represents the actual utilization of the link (i.e. as measured in the router). For a bundled link, bandwidth utilization is defined to be the sum of the component link bandwidth utilizations."; } } // performance-metric-attributes From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Wednesday, July 18, 2018 10:40 AM To: TEAS WG <teas@ietf.org> Cc: IETF IPPM WG <ippm@ietf.org> Subject: [Teas] STAMP YANG model Dear TEAS WG, appreciate your consideration, comments, and questions of the STAMP (Simple Two-way Active Measurement Protocol) YANG model<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/>. In addition to controlling PM test session(s) model includes reportable performance metrics. Regards, Greg
- [ippm] STAMP YANG model Greg Mirsky
- Re: [ippm] [Teas] STAMP YANG model Leeyoung