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

[Qin Wu <[e-mail]>]

Thanks Greg for feedback, please see my reply inline below.
发件人: Greg Mirsky [mailto:[e-mail]]
发送时间: 2017年10月24日 23:18
收件人: Qin Wu
抄送: [e-mail]; [e-mail]; Carlos Pignataro; Ron Bonica; [e-mail]; Benoit Claise; [e-mail]
主题: 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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
发送时间: 2017年10月20日 20:34
收件人: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
抄送: Carlos Pignataro; Ron Bonica; [e-mail]<mailto:[e-mail]>; Benoit Claise; [e-mail]<mailto:[e-mail]>
主题: 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].
”
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.

     *   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.";
              }
”
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.

  *   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.";
                }



”
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.



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


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

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
[e-mail]<mailto:[e-mail]> mailing lists by 2017-10-25. Exceptionally, comments may be
sent to [e-mail]<mailto:[e-mail]> 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.




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