Re: [Teas] STAMP YANG model

Leeyoung <> Thu, 19 July 2018 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E7D21310F3; Thu, 19 Jul 2018 07:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4nVEwZF9h3hG; Thu, 19 Jul 2018 07:38:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F08E8130F4A; Thu, 19 Jul 2018 07:38:31 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 8AB34528F1E53; Thu, 19 Jul 2018 15:38:28 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 19 Jul 2018 15:38:29 +0100
Received: from ([]) by ([]) with mapi id 14.03.0399.000; Thu, 19 Jul 2018 07:38:25 -0700
From: Leeyoung <>
To: Greg Mirsky <>, TEAS WG <>
Thread-Topic: [Teas] STAMP YANG model
Thread-Index: AQHUHq3N91c+saoAVEy+NoeU6/xIyKSWlKgQ
Date: Thu, 19 Jul 2018 14:38:24 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E173D03D892sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Teas] STAMP YANG model
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 (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.


------------------excerpt from iert-te-types---------------------------------------------

grouping performance-metric-attributes {
      "Link performance information in real time.";
      "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
    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

        "Packet loss as a percentage of the total traffic sent
         over a configurable interval. The finest precision is
    leaf unidirectional-residual-bandwidth {
      type rt-types:bandwidth-ieee-float32;
        "Residual bandwidth that subtracts tunnel
         reservations from Maximum Bandwidth (or link capacity)
         [RFC3630] and provides an aggregated remainder across QoS
    leaf unidirectional-available-bandwidth {
      type rt-types:bandwidth-ieee-float32;
        "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;
        "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
  } // performance-metric-attributes

From: Teas [] On Behalf Of Greg Mirsky
Sent: Wednesday, July 18, 2018 10:40 AM
To: TEAS WG <>
Subject: [Teas] STAMP YANG model

appreciate your consideration, comments, and questions of the STAMP (Simple Two-way Active Measurement Protocol) YANG model<>g/>. In addition to controlling PM test session(s) model includes reportable performance metrics.