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 Mirsky <[e-mail]>]

Dear All,
I was under impression that that question of oam-neighboring-tps has been
discussed and since authors couldn't produce technical rationale for this
object we've agreed that it will be removed altogether from the grouping
connectionless-oam-tps. But authors just changed name from level to
position but had missed to synchronize descriptions in the model and in
section 3.3. The later still refers to vertical layers:

                     "List of related neighboring test points in adjacent
                     layers up and down the stack for the same interface
                     that are related to the current test point.";

while the model insists that it is peering relationship:

        description
          "The relative position
           of neighboring test point
           corresponding to the current
           test point. Level 0 indicates no neighboring
           test points placed before or after the current

           test point in the same layer.-1 means there is
           a neighboring test point placed before the current
           test point in the same layer and +1 means there is
           a neighboring test point placed after the current
           test point in same layer.";

So, what is it? Perhaps it is time to remove list oam-neighboring-tps
altogether also because having it s fixed size list is plain wrong. (Sorry
for being so blunt but I commented too many times on the same to no avail
from the authors).

Regards,
Greg

On Thu, Oct 26, 2017 at 9:26 AM, Qin Wu <[e-mail]> wrote:

> Thanks Greg, will consider that.
>
>
>
> -Qin
>
> *发件人:* Greg Mirsky [mailto:[e-mail]]
> *发送时间:* 2017年10月25日 20:55
> *收件人:* 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 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 <[e-mail]> wrote:
>
> 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]> 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]]
> *发送时间:* 2017年10月20日 20:34
> *收件人:* [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
>
>
>
> 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]> 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] mailing lists by 2017-10-25. Exceptionally, comments may be
> sent to [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]
> https://www.ietf.org/mailman/listinfo/lime
>
>
>
>
>
>
>
>
>