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


> 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-connec
>> tionless-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
>>
>
>