Telechat Review of draft-ietf-ippm-alt-mark-13

Request Review of draft-ietf-ippm-alt-mark
Requested rev. no specific revision (document currently at 14)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2017-11-28
Requested 2017-10-23
Authors Giuseppe Fioccola, Alessandro Capello, Mauro Cociglio, Luca Castaldelli, Mach Chen, Lianshu Zheng, Greg Mirsky, Tal Mizrahi
Draft last updated 2017-11-21
Completed reviews Secdir Last Call review of -13 by Taylor Yu (diff)
Genart Last Call review of -10 by Linda Dunbar (diff)
Intdir Last Call review of -10 by Brian Haberman (diff)
Opsdir Last Call review of -12 by Éric Vyncke (diff)
Rtgdir Last Call review of -10 by Russ White (diff)
Genart Telechat review of -12 by Linda Dunbar (diff)
Genart Telechat review of -13 by Linda Dunbar (diff)
Opsdir Telechat review of -13 by Éric Vyncke (diff)
Assignment Reviewer Éric Vyncke 
State Completed
Review review-ietf-ippm-alt-mark-13-opsdir-telechat-vyncke-2017-11-21
Reviewed rev. 13 (document currently at 14)
Review result Has Nits
Review completed: 2017-11-21


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