Re: [Teas] STAMP YANG model

Leeyoung <leeyoung@huawei.com> Thu, 19 July 2018 14:38 UTC

Return-Path: <leeyoung@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@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/teas/GrhkeGD8Fjoy_qcDan_wkz2nBb0>
Subject: Re: [Teas] STAMP YANG model
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-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/>g/>. In addition to controlling PM test session(s) model includes reportable performance metrics.

Regards,
Greg