Subject: [Teas] STAMP YANG model

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Jul 2018 08:40:26 -0700

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

---

From: Leeyoung <[email-masked]>
Date: Thu, 19 Jul 2018 14:38:24 +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:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, July 18, 2018 10:40 AM
To: TEAS WG <[email-masked]>
Cc: IETF IPPM WG <[email-masked]>
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