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-connec
tion-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 <iesg-secretary@xxxxxxxx> 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
ietf@xxxxxxxx mailing lists by 2017-10-25. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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-connec tionless-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
Lime@xxxxxxxx
https://www.ietf.org/mailman/listinfo/lime