Subject: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 11 Oct 2017 06:40:50 -0700

The IESG has received a request from the Layer Independent OAM Management in
the Multi-Layer Environment WG (lime) to consider the following document: -
'Generic YANG Data Model for Connectionless Operations, Administration,
   and Maintenance(OAM) protocols'
  <draft-ietf-lime-yang-connectionless-oam-11.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2017-10-25. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   This document presents a base YANG Data model for connectionless
   Operations Administration, and Maintenance(OAM) protocols.  It
   provides a technology-independent abstraction of key OAM constructs
   for connectionless protocols.  The base model presented here can be
   extended to include technology specific details.  This is leading to
   uniformity between OAM protocols and support both nested OAM
   workflows (i.e., performing OAM functions at different or same levels
   through a unified interface) and interacting OAM workflows ( i.e.,
   performing OAM functions at same levels through a unified interface).

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Thu, 12 Oct 2017 09:49:12 +0000

As a team member implementing OAM protocols consuming this model, I have read the draft and support progressing it.
Thanks
Prasad

-----Original Message-----
From: IETF-Announce [mailto:[email-masked]] On Behalf Of The IESG
Sent: Wednesday, October 11, 2017 7:11 PM
To: IETF-Announce <[email-masked]>
Cc: Carlos Pignataro (cpignata) <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; Benoit Claise (bclaise) <[email-masked]>; [email-masked]; [email-masked]
Subject: Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

The IESG has received a request from the Layer Independent OAM Management in the Multi-Layer Environment WG (lime) to consider the following document: - 'Generic YANG Data Model for Connectionless Operations, Administration,
   and Maintenance(OAM) protocols'
  <draft-ietf-lime-yang-connectionless-oam-11.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked] mailing lists by 2017-10-25. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Oct 2017 01:24:12 -0700

Dear All,
please kindly consider my comments on draft-ietf-lime-yan
g-connectionless-oam

On Wed, Oct 11, 2017 at 6:40 AM, The IESG <[email-masked]> wrote:

> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 19 Oct 2017 16:01:38 +0000

Dear Greg,

The LIME WG and draft-ietf-lime-yang-connectionless-oam editors have been considering all your comments, and will continue to do so.

For clarity, however, what are you referring to on this one-liner?

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Oct 19, 2017, at 4:24 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear All,
please kindly consider my comments on draft-ietf-lime-yang-connectionless-oam

On Wed, Oct 11, 2017 at 6:40 AM, The IESG <[email-masked]<mailto:[email-masked]>> wrote:

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2017-10-25. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

_______________________________________________
Lime mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lime

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Oct 2017 09:12:01 -0700

Dear Carlos, et.al,
I sincerely apologize for sending the empty message. I am working on the
substantive comments to both documents that are in the IETF LC at the
moment and will share them with all by Monday, October 23rd.

Regards,
Greg

On Thu, Oct 19, 2017 at 9:01 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Dear Greg,
>
> The LIME WG and draft-ietf-lime-yang-connectionless-oam editors have been
> considering all your comments, and will continue to do so.
>
> Carlos Pignataro, [email-masked]
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
> On Oct 19, 2017, at 4:24 AM, Greg Mirsky <[email-masked]> wrote:
>
> Dear All,

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 20 Oct 2017 05:34:24 -0700

Dear All,
presented below:

   - 1. Introduction
      - clear and technical definitions of connection-oriented (CO) and
      connectionless (CL) network are absent. Note that referenced RFC
7276 does
      not provide that either as differentiation based on amount of
configuration
      required to instantiate a network changes, decreases as result of further
      progress in network operation automation. I propose to use definitions CO
      and CL forwarding paradigms provided in section 6.3.1 G.800 Unified
      functional architecture of transport networks, as these are clear,
      technical and are broadly used in the industry.
      - characterization of the subject of the document as "YANG Data model
      for connectionless OAM protocols" is not accurate considering CO/CL
      definitions in G.800. I propose to refer to "OAM protocols for
      connectionless networks" since the same OAM protocols may be used in both
      CO-PS and CL-PS networks, e.g. LSP Ping used in both MPLS-TP and IP/MPLS
      networks.
   - 3. Overview of the Connectionless OAM Model
      - "... the 'test-point-location-info', is a common aspect of every
      'test-point-location' - there's no YANG object test-point-location in the
      presented data model.
   - 3.3 OAM Neighboring Layers
      - I find this part of the model under-developed. First, the
      terminology - layers imply vertical, client-server relationship while
      downstream/upstream - peering relationship on the same layer. Second, the
      limited visibility due to technology-level limitation that supports only
      reference to the immediate neighboring layer but not to next-to-next
      neighbor. I consider this to be major problem for common model that
      intended for multi-layer environment.
   - 3.4 Test Point Locations Information
      - reference to non-existent "tp-tool" and "OAM-neighboring Layers"
       groupings
   - 4. YANG OAM Model
      - I think that use of prefix 'coam' for data model of OAM in
      connectionless networks is limiting considering that there should be
      another model of OAM in connection-oriented networks. Acronyms CL and CO
      usually used to refer to connectionless and connection-oriented networks
      respectively. Thus I suggest to use 'cl-oam' as prefix for the data model
      presented in this document and 'co-oam' instead of 'goam'
      in draft-ietf-lime-yang-connection-oriented-oam-model.
      - I find time-resolution to be superfluous and thus overcomplicating
      the model. I suggest use type-interval-type instead and consider for the
      update of yang:ietf-yang-types defined in RFC 6991.
      -

      session-delay-statistics and session-jitter-statistics are too
limiting in many dimensions - no support to reflect one-way (far-end
and near-end) and round-trip measurements for the same test session,
and too few metrics., e.g. no report of percentile.

      -

      session-delay-statistics does not reflect type of delay
variation being calculated. As analyzed in RFC 5481, PDV and IPDV
characterize different conditions (Section 5) and at least reflecting
which one being calculated and reported is very informative.

      -

      I cannot find anything that directly reports packet loss
statistics (packet loss and packet loss ratio) for the given test
session. Is that intentional? ICMP ping is capable to report number of
lost packets in round-trip.

      -

      using uint32 in session-packet-statistics seems risking overrun
of counters especially for test sessions running  forever.

      -

      I believe that using 0 to indicate that the parameter is not
being reported, throughout several statistics groupings, creates
problem when the true value is 0, e.g. rx-bad-packet;

      -

      connectionless-oam-layers - what considerations were discussed
to arrive to liming number of neighboring test points to 128?

      -

      tp-tools:continuity-check you may add RFC 8029 to the list of references

      -

      tp-tools:path-discovery RFC 8029 obsoletes RFC 4379 as standard
for LSP Ping

      -

      timestamp grouping is limited to PTPv2 Truncated and NTPv4
64-bit format [RFC5905]. What about other formats, e.g. ICMP
Timestamp, NTPv4 32-bit, a.k.a. short, or PTPv2 80-bits long?

      - 5.1.1.2 Test point attributes extension
      - reference to non-existing "test-point-location" list
   - 5.1.2 Schema Mount
      - reference to non-existing "test-point-location" list
   - 5.2.1.2 Test point attributes extension
      - reference to non-existing "test-point-location" list
   - 5.2.2 Schema Mount
      - reference to non-existing "test-point-location" list

In summary, I find several serious issues with the current version of the
data model presented in the document, e.g. use of 0 to indicate unreported
parameter and underdeveloped layering model.

Regards,
Greg

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Oct 2017 08:28:30 +1300

Greg,
On 21/10/2017 01:34, Greg Mirsky wrote:
...
> which one being calculated and reported is very informative.

I had similar comments on draft-ietf-lime-yang-connectionless-oam-methods-09
in my Gen-ART review at
https://mailarchive.ietf.org/arch/msg/gen-art/qA38WYm5ookOePfnhqO4yM09cvc.
I haven't reviewed draft-ietf-lime-yang-connectionless-oam itself,
but it seems that the authors have chosen to leave quite a few things
under-defined, which bothers me from the interoperability viewpoint.
Presumably the existing implementations have taken specific decisions
on these points, which could be documented, even as default recommendations?

Regards
     Brian

---

From: Qin Wu <[email-masked]>
Date: Mon, 23 Oct 2017 03:31:26 +0000

Thanks Greg for providing additional input to help make the model more extensible and reusable.
Please see my reply inline below.

-Qin
发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2017年10月20日 20:34
收件人: [email-masked]; [email-masked]
抄送: Carlos Pignataro; Ron Bonica; [email-masked]; Benoit Claise; [email-masked]
主题: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Dear All,
please kindly consider my comments on draft-ietf-lime-yang-connectionless-oam presented below:

  *   1. Introduction

     *   clear and technical definitions of connection-oriented (CO) and connectionless (CL) network are absent. Note that referenced RFC 7276 does not provide that either as differentiation based on amount of configuration required to instantiate a network changes, decreases as result of further progress in network operation automation. I propose to use definitions CO and CL forwarding paradigms provided in section 6.3.1 G.800 Unified functional architecture of transport networks, as these are clear, technical and are broadly used in the industry.
[Qin]: I believe RFC7276 and G.800 share the similar paradigms but capture the different aspect of the key difference between CO and CL, I would suggest to harmonize the different aspect of these key differences together and add another reference to G.800 as follows:
NEW TEXT:
“
In connection-oriented technologies,
   a connection is established prior to the transmission of data.  After
   connection is established, no additional control information such as
   signaling or operations and maintenance information is required to
   transmit the data.  In connectionless technologies, data is
   typically sent between end points without prior arrangement, but
   control information is required to identify destination [G.800][RFC7276].
”

     *   characterization of the subject of the document as "YANG Data model for connectionless OAM protocols" is not accurate considering CO/CL definitions in G.800. I propose to refer to "OAM protocols for connectionless networks" since the same OAM protocols may be used in both CO-PS and CL-PS networks, e.g. LSP Ping used in both MPLS-TP and IP/MPLS networks.
      [Qin]: Okay ,Sounds good to me.

  *   3. Overview of the Connectionless OAM Model

     *   "... the 'test-point-location-info', is a common aspect of every 'test-point-location' - there's no YANG object test-point-location in the presented data model.
   [Qin]: It is Typo. It should be ‘test-point-locations’, fixed. Thanks.

  *   3.3 OAM Neighboring Layers

     *   I find this part of the model under-developed. First, the terminology - layers imply vertical, client-server relationship while downstream/upstream - peering relationship on the same layer. Second, the limited visibility due to technology-level limitation that supports only reference to the immediate neighboring layer but not to next-to-next neighbor. I consider this to be major problem for common model that intended for multi-layer environment.
[Qin]: We discussed this before, I revisit this section and understand your concern now , I would like to suggest to remove layer related text since it introduce confusion, I would suggest to change technology-level into position since what we try to define are OAM Neighboring Test points list. We will focus on test points related to one single layer. One can use position to capture of order of these test points and also identify test point at the left layer boundary and test point at the right layer boundary. The proposed changes as follows:
“
3.3.  OAM neighboring test points

   As typical networks have a multi-layer architecture, the set of OAM
   protocols similarly take a multi-layer structure; each layer may has
   its own OAM protocol [RFC7276] and is corresponding to specific
   administrative domain and has associated test points.  OAM
   neighboring test points are referred to a list of neighboring test
   points in the same layer that are related to current test point.
   This allows users to easily navigate between related neighboring
   layer to efficiently troubleshoot a defect.  In this model,
   'position' leaf defines the relative position of neighboring test
   point corresponding to the current test point in the same layer , and
   is provided to allow correlation of faults at different location . If
   there is one neighboring test point placed before the current test
   point, 'position' leaf is set to -1.  If there is one neighboring
   test point placed after the current test point, 'position' leaf is
   set to 1.  If there is no neighboring test point placed before or
   after the current test point, 'position' leaf is set to 0.

                list oam-neighboring-tps {
                  key "index";
                  leaf index {
                     type uint16 {
                        range "0..65536";
                     }
                    description
                     "Index of a list of neighboring test points
                      in the same layer ";
                  }
                  leaf position {
                      type int8 {
                           range "-1..1";
                      }
                      description
                        "The relative position
                        of neighboring test point
                        corresponding to the current
                        test point";
                  }
                  description
                     "List of related neighboring test points in the same layer.";
              }
”

  *   3.4 Test Point Locations Information

     *   reference to non-existent "tp-tool" and "OAM-neighboring Layers" groupings
             [Qin]: It is typo, oam-neighboring layers should be corrected as “oam-neighboring-tps” now.

  *   4. YANG OAM Model

     *   I think that use of prefix 'coam' for data model of OAM in connectionless networks is limiting considering that there should be another model of OAM in connection-oriented networks. Acronyms CL and CO usually used to refer to connectionless and connection-oriented networks respectively. Thus I suggest to use 'cl-oam' as prefix for the data model presented in this document and 'co-oam' instead of 'goam' in draft-ietf-lime-yang-connection-oriented-oam-model.
                [Qin]:Good proposal, I like it.

     *   I find time-resolution to be superfluous and thus overcomplicating the model. I suggest use time-interval-type instead and consider for the update of yang:ietf-yang-types defined in RFC 6991.
              [Qin]:  Time resolution is referred to time unit, sure we can change it into time-interval-type as you suggested.

o    session-delay-statistics and session-jitter-statistics are too limiting in many dimensions - no support to reflect one-way (far-end and near-end) and round-trip measurements for the same test session, and too few metrics., e.g. no report of percentile.

             [Qin]: We have protocol-id and protocol-id-meta-data to be defined in draft-ietf-lime-yang-connectionless-oam-methods-09 which can be used to indicate whether it is one way measurement, or two way

measurements. Please see my reply for loss ration for report of percentile.

o    session-delay-statistics does not reflect type of delay variation being calculated. As analyzed in RFC 5481, PDV and IPDV characterize different conditions (Section 5) and at least reflecting which one being calculated and reported is very informative.

                [Qin]: We have protocol-id and protocol-id-meta-data to be defined in draft-ietf-lime-yang-connectionless-oam-methods-09 which can be used to indicate whether IPDV is used or PDV is used, Based on Brian’s

   suggestion, we could set IPDV as default for jitter measurement.

o    I cannot find anything that directly reports packet loss statistics (packet loss and packet loss ratio) for the given test session. Is that intentional? ICMP ping is capable to report number of lost packets in round-trip.

              [Qin]: We do have a parameter ‘packet-drops-count’ for packet-loss, we can change it into “packet-loss-count” as you suggested, in addition, we can add a new parameter for packet loss ration as follows:

“
      leaf packet-loss-count {
        type uint32 {
        range "0..4294967295";
        }
       default "0";
        description
          "Total received packet drops count.
          If the value is 4294967295, it indicates
          packet drops count is overrun.";
      }

          leaf loss-ratio{
                        type uint8{
                                range 0..100;
                        }
                description
                 "Loss ratio of the packets. Express as percentage
                 of packets lost with respect to packets sent.";
                }

”

o    using uint32 in session-packet-statistics seems risking overrun of counters especially for test sessions running  forever.

[Qin]: Good point, we could set up-limit for session-packet-statistics data, if statistics data reach up-lmit, it wil indicate counter overrun happens.

o    I believe that using 0 to indicate that the parameter is not being reported, throughout several statistics groupings, creates problem when the true value is 0, e.g. rx-bad-packet;

[Qin]:Good point, we will remove to use 0 to indicate the parameter is not being reported.

o    connectionless-oam-layers - what considerations were discussed to arrive to liming number of neighboring test points to 128?

[Qin]: Okay, we can change uint8 into uint16 to support more test points that can be recorded. But please note that each test point actually only record his neighboring test points, if each test points record a complete

List of test points in one test, that will result in a lot of duplicated data associated with each test point.

o    tp-tools:continuity-check you may add RFC 8029 to the list of references

[Qin]: Accepted, thanks.

o    tp-tools:path-discovery RFC 8029 obsoletes RFC 4379 as standard for LSP Ping

[Qin]: Accepted, thanks.

o    timestamp grouping is limited to PTPv2 Truncated and NTPv4 64-bit format [RFC5905]. What about other formats, e.g. ICMP Timestamp, NTPv4 32-bit, a.k.a. short, or PTPv2 80-bits long?

[Qin]: Here is the proposed change to address your comments:

“
  grouping timestamp {
    description
      "Grouping for timestamp.";
    leaf timestamp-type {
      type identityref {
      base timestamp-type;
      }
      description
        "Type of Timestamp, such as Truncated PTP, NTP.";
    }
    container timestamp-64bit {
        when "derived-from-or-self(../type, 'cl-oam:truncated-ptp')"+
       "or derived-from-or-self(../type,'cl-oam:ntp64')" {
         description
          "Only applies when Truncated NTP or 64bit NTP Timestamp.";
        }
      leaf timestamp-sec {
      type uint32;
      description
        "Absolute timestamp in seconds as per IEEE1588v2
         or seconds part in 64-bit NTP timestamp.";
       }
      leaf timestamp-nanosec {
      type uint32;
      description
        "Fractional part in nanoseconds as per IEEE1588v2
         or Fractional part in 64-bit NTP timestamp.";
      }
      description
      "Container for 64bit timestamp.";
    }
    container timestamp-80bit {
        when "derived-from-or-self(../type, 'cl-oam:ptp80')"{
         description
          "Only applies when 80bit PTP Timestamp.";
        }
          if-feature ptp-long-format;
      leaf timestamp-sec {
      type uint64 {
     range "0..281474976710656";
      }
      description
        "48bit Timestamp in seconds as per IEEE1588v2.";
       }
      leaf timestamp-nanosec {
      type uint32;
      description
        "Fractional part in nanoseconds as per IEEE1588v2
         or Fractional part in 64-bit NTP timestamp.";
      }
      description
      "Container for 64bit timestamp.";
    }
       container ntp-timestamp-32bit {
        when "derived-from-or-self(../type, 'cl-oam:truncated-ntp')"{
         description
          "Only applies when 32 bit NTP Short format Timestamp.";
        }
          if-feature ntp-short-format;
      leaf timestamp-sec {
      type uint16;
      description
        "Timestamp in seconds as per short format NTP.";
       }
      leaf timestamp-nanosec {
      type uint16;
      description
        "Truncated Fractional part in 16-bit NTP timestamp.";
      }
      description
      "Container for 64bit timestamp.";
    }
     container icmp-timestamp-32bit {
        when "derived-from-or-self(../type, 'cl-oam:icmp-ntp')"{
         description
          "Only applies when Truncated NTP or 64bit NTP Timestamp.";
        }
          if-feature icmp-timestamp;
      leaf timestamp-millisec {
      type uint32;
      description
        "timestamp in milliseconds for ICMP timestamp.";
       }
      description
      "Container for 32bit timestamp.";
    }
  }

”

  *   5.1.1.2 Test point attributes extension

     *   reference to non-existing "test-point-location" list
[Qin]: Same typo as you mentioned above, it should be “test-point-locations”.

  *   5.1.2 Schema Mount

     *   reference to non-existing "test-point-location" list
[Qin]: Same as above, fixed.

  *   5.2.1.2 Test point attributes extension

     *   reference to non-existing "test-point-location" list
[Qin]: Same as above, fixed.

  *   5.2.2 Schema Mount

     *   reference to non-existing "test-point-location" list
[Qin]: Same as above, fixed.
In summary, I find several serious issues with the current version of the data model presented in the document, e.g. use of 0 to indicate unreported parameter and underdeveloped layering model.

Regards,
Greg

Abstract

---

From: Qin Wu <[email-masked]>
Date: Mon, 23 Oct 2017 03:40:38 +0000

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[email-masked]] 
发送时间: 2017年10月21日 3:29
收件人: Greg Mirsky; [email-masked]; [email-masked]
抄送: Carlos Pignataro; [email-masked]; [email-masked]
主题: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Greg,

I had similar comments on draft-ietf-lime-yang-connectionless-oam-methods-09
in my Gen-ART review at
https://mailarchive.ietf.org/arch/msg/gen-art/qA38WYm5ookOePfnhqO4yM09cvc.
I haven't reviewed draft-ietf-lime-yang-connectionless-oam itself, but it seems that the authors have chosen to leave quite a few things under-defined, which bothers me from the interoperability viewpoint.
Presumably the existing implementations have taken specific decisions on these points, which could be documented, even as default recommendations?

[Qin]: Thanks Brian for Good suggestion, here is proposed change to address your comments:
OLD TEXT:
"
  grouping session-delay-statistics {
    description
      "Grouping for per session delay statistics";

    container session-delay-statistics {
      description
        "Session delay summarised information.";
 ........

  grouping session-jitter-statistics {
    description
      "Grouping for per session jitter statistics";
    container session-jitter-statistics {
      description
        "Session jitter summarised information.";
.......
"
NEW TEXT:
"
  grouping session-delay-statistics {
    description
      "Grouping for per session delay statistics";
    container session-delay-statistics {
      description

        "Session delay summarised information.By default,
         one way measurement protocol (e.g., OWAMP)is used
         to measure delay. When two way measurement protocol
         (e.g., TWAMP) is used instead, it can be indicated
         using and protocol-id defined in RPC operation of
         draft-ietf-lime-yang-connectionless-oam-methods,i.e.,
         set protocol-id as OWAMP. Note that only one measurement
         protocol for delay is specified every time for interoperability reason.";
......

  grouping session-jitter-statistics {
    description
      "Grouping for per session jitter statistics";
    container session-jitter-statistics {
      description
        "Session jitter summarised information. By default,
         jitter is measured using IP Packet Delay Variation
         (IPDV) as defined in RFC3393. When the other measurement
         method is used instead(e.g.,Packet Delay Variation used in
         Y.1540, it can be indicated using protocol-id-meta-data
         defined in RPC operation of
         draft-ietf-lime-yang-connectionless-oam-methods. Note that
         only one measurement method for jitter is specified every time
         for interoperability reason.";
.....
"
Regards
     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Oct 2017 16:53:22 +1300

Yes, that looks like a significant improvement. Thanks!

Regards
   Brian

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Oct 2017 08:18:25 -0700

Hi Qin,
thank you for your expedient and careful consideration of my comments. I'm
glad that we've already in agreement on so many. I've added notes on those
that, in my view, need some more discussions. Please find them in-line
tagged GIM>>.

Regards,
Greg

On Sun, Oct 22, 2017 at 8:31 PM, Qin Wu <[email-masked]> wrote:

> *发件人:* Greg Mirsky [mailto:[email-masked]]
> *发送时间:* 2017年10月20日 20:34
> *收件人:* [email-masked]; [email-masked]
> *抄送:* Carlos Pignataro; Ron Bonica; [email-masked]; Benoit Claise;
> [email-masked]
> *主题:* Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt>
> (Generic YANG Data Model for Connectionless Operations, Administration, and
> Maintenance(OAM) protocols) to Proposed Standard
>
>
>
> Dear All,
>
>       connectionless (CL) network are absent. Note that referenced RFC 7276 does
>       not provide that either as differentiation based on amount of configuration
> [Qin]: I believe RFC7276 and G.800 share the similar paradigms but capture
> the different aspect of the key difference between CO and CL, I would
> suggest to harmonize the different aspect of these key differences together
> and add another reference to G.800 as follows:
>
> NEW TEXT:
>
> “
>
GIM>> If we consider, for example, MPLS-TP domain and L3VPN over IP/MPLS
domain, then the configuration aspect, in my opinion, becomes less distinct
while the forwarding paradigm is invariant, remains the same.

> [Qin]: We discussed this before, I revisit this section and understand
> your concern now , I would like to suggest to remove layer related text
> since it introduce confusion, I would suggest to change technology-level
> into position since what we try to define are OAM Neighboring Test points
> list. We will focus on test points related to one single layer. One can use
> position to capture of order of these test points and also identify test
> point at the left layer boundary and test point at the right layer
> boundary. The proposed changes as follows:
>
> “
>
GIM>> I think that if we concentrate on OAM on particular network layer,
then reference to multi-layer character of modern networks is unnecessary
and somewhat artificial. As for test points in the same layer, then
traceroute suppose to return ordered list of Test Points between the Sender
and Receiver. Because there could be ECMP sub-domains along the path, model
should be able to differentiate with some entropy key. OAM visibility into
other administrative domains obviously brings security consideration issues
and, I'd expect, be carefully controlled and try to hide identity of the
domain. Hence, I think that 'position' is hardly usable parameter.

>       the model. I suggest use time-interval-type instead and consider
>       for the update of yang:ietf-yang-types defined in RFC 6991.
>
>               [Qin]:  Time resolution is referred to time unit, sure we
> can change it into time-interval-type as you suggested.
>
> GIM>> Packet loss and, as result, loss ratio in modern networks is very
low. I suggest changing loss-ratio type from uint8 to new type percentage,
defined as:
   typedef percentage {
        type decimal64 {
                fraction-digits 5;
        }
        description "Percentage";
   }
 GIM>> I think that counter overrun case indicator requires separate
parameter. Using 4294967295 may produce negative false when running in
forever mode.

---

From: Qin Wu <[email-masked]>
Date: Wed, 25 Oct 2017 03:06:39 +0000

Thanks Greg for feedback, please see my reply inline below.
发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2017年10月24日 23:18
收件人: Qin Wu
抄送: [email-masked]; [email-masked]; Carlos Pignataro; Ron Bonica; [email-masked]; Benoit Claise; [email-masked]
主题: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Hi Qin,
thank you for your expedient and careful consideration of my comments. I'm glad that we've already in agreement on so many. I've added notes on those that, in my view, need some more discussions. Please find them in-line tagged GIM>>.

Regards,
Greg

On Sun, Oct 22, 2017 at 8:31 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Greg for providing additional input to help make the model more extensible and reusable.
Please see my reply inline below.

-Qin
发件人: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2017年10月20日 20:34
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: Carlos Pignataro; Ron Bonica; [email-masked]<mailto:[email-masked]>; Benoit Claise; [email-masked]<mailto:[email-masked]>
主题: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Dear All,

  *   1. Introduction

GIM>> If we consider, for example, MPLS-TP domain and L3VPN over IP/MPLS domain, then the configuration aspect, in my opinion, becomes less distinct while the forwarding paradigm is invariant, remains the same.

[Qin]: Thanks.

GIM>> I think that if we concentrate on OAM on particular network layer, then reference to multi-layer character of modern networks is unnecessary and somewhat artificial. As for test points in the same layer, then traceroute suppose to return ordered list of Test Points between the Sender and Receiver. Because there could be ECMP sub-domains along the path, model should be able to differentiate with some entropy key. OAM visibility into other administrative domains obviously brings security consideration issues and, I'd expect, be carefully controlled and try to hide identity of the domain. Hence, I think that 'position' is hardly usable parameter.

[Qin]: Thanks for your comments on this, yes recording test point list in the same layer is not good use case, harmonizing with your comments and Gen-art review comments, we have removed same layer and rewrite this section based on Gen-art reviewer’s input and suggestions. Thanks again.

  *   4. YANG OAM Model

“
      leaf packet-loss-count {
        type uint32 {
        range "0..4294967295";
        }
       default "0";
        description

          leaf loss-ratio{
                        type uint8{
                                range 0..100;
                        }
                description

”
GIM>> Packet loss and, as result, loss ratio in modern networks is very low. I suggest changing loss-ratio type from uint8 to new type percentage, defined as:
   typedef percentage {
        type decimal64 {
                fraction-digits 5;
        }
        description "Percentage";
   }

[Qin]: Good proposal, accepted.
 GIM>> I think that counter overrun case indicator requires separate parameter. Using 4294967295 may produce negative false when running in forever mode.

[Qin]: Note that counter  is unsigned integer, it will not produce negative false, in my understanding. I doubt we should add such complexity to data model by introducing another parameter, we can leave this to implementation details.

[Qin]: Accepted, thanks.

[Qin]: Accepted, thanks.

“
  grouping timestamp {
    description

”

  *   5.1.2 Schema Mount

  *   5.2.2 Schema Mount

Regards,
Greg

Abstract

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 25 Oct 2017 05:54:34 -0700

Hi Qin,
thank you for your thoughtful consideration of my comments.
I agree to leave mechanism of overrun indication to implementation but I
believe that it will be really helpful to add a sub-section that highlights
specific of running tests in forever mode and points to issues that require
particular attention.

Regards,
Greg

On Tue, Oct 24, 2017 at 8:06 PM, Qin Wu <[email-masked]> wrote:

> *发送时间:* 2017年10月24日 23:18
> *收件人:* Qin Wu
> *抄送:* [email-masked]; [email-masked];
> Carlos Pignataro; Ron Bonica; [email-masked]; Benoit Claise;
> [email-masked]
> [Qin]: Thanks for your comments on this, yes recording test point list in
> the same layer is not good use case, harmonizing with your comments and
> Gen-art review comments, we have removed same layer and rewrite this
> section based on Gen-art reviewer’s input and suggestions. Thanks again.
>
>
> [Qin]: Note that counter  is unsigned integer, it will not produce
> negative false, in my understanding. I doubt we should add such complexity
> to data model by introducing another parameter, we can leave this to
> implementation details.
>
>
>
>
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 26 Oct 2017 01:26:04 +0000

Thanks Greg, will consider that.

-Qin
发送时间: 2017年10月25日 20:55

Hi Qin,
thank you for your thoughtful consideration of my comments.
I agree to leave mechanism of overrun indication to implementation but I believe that it will be really helpful to add a sub-section that highlights specific of running tests in forever mode and points to issues that require particular attention.

Regards,
Greg

On Tue, Oct 24, 2017 at 8:06 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Greg for feedback, please see my reply inline below.
发件人: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2017年10月24日 23:18
收件人: Qin Wu
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Carlos Pignataro; Ron Bonica; [email-masked]<mailto:[email-masked]>; Benoit Claise; [email-masked]<mailto:[email-masked]>
主题: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Hi Qin,

Regards,
Greg

-Qin

Dear All,

  *   1. Introduction

[Qin]: Thanks.

  *   4. YANG OAM Model

“
      leaf packet-loss-count {
        type uint32 {
        range "0..4294967295";
        }
       default "0";
        description

          leaf loss-ratio{
                        type uint8{
                                range 0..100;
                        }
                description

”

[Qin]: Accepted, thanks.

[Qin]: Accepted, thanks.

“
  grouping timestamp {
    description

”

  *   5.1.2 Schema Mount

  *   5.2.2 Schema Mount

Regards,
Greg

Abstract