Telechat Review of draft-ietf-ippm-alt-mark-13
review-ietf-ippm-alt-mark-13-opsdir-telechat-vyncke-2017-11-21-00
review-ietf-ippm-alt-mark-13-opsdir-telechat-vyncke-2017-11-21-00
I reviewed the document " Alternate Marking method for passive and hybrid performance monitoring" (draft-ietf-ippm-alt-mark-12) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. See also RFC 5706. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a method to perform packet loss, delay and jitter measurements on live traffic using a passive method applicable to any traffic (MPLS, Ethernet, IP, ...). The idea is to split packet flows in buckets and count packet in each bucket on multiple points (packet loss mainly), the buckets are delimited by marking/coloring existing packets in the flow (color switching can be based on time or packet count). The document presents also two strategies to color packets: - Flow-based but then we can wonder whether the receiving measurement point will be on the path - Link-based, probably less useful but providing accurate information Section 3.1.1 briefly touches one operational issue in the sense that coloring in multiple nodes should not conflict with each other. This requires a careful design & configuration. Section 3.2.3 briefly talks about how the counters/measurements are centralized by 'FTP or SNMP' (also referred in Section 4.2). In my opinion, this is too vague, there should at least be a companion document describing which method/protocol must be used (IPFIX, SNMP, ...). The one-way delay measurement requires a precis time synchronization. Section 5.1 presents an operational experiment at Telecom Italia using marking in the least-significant bits of the DSCP; coloring being done by changing the QoS marking policy periodically (5 minutes). Counting is done via ACL. Very surprising in 2017, section 5.2 mention an example for alternate marking which is IPv4 only. I like the overall idea and would recommend some changes in the document: - Abstract should mention that this method works reliably only within a single management/operation domain - Refer to another document (to be created?) about how counters are collected - Refer to another document (to be created?) about how the coloring if provisionned Hope it helps -éric