Last Call Review of draft-ietf-ippm-alt-mark-12
review-ietf-ippm-alt-mark-12-opsdir-lc-vyncke-2017-10-23-00

Request Review of draft-ietf-ippm-alt-mark
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-09-27
Requested 2017-09-13
Requested by Spencer Dawkins
Other Reviews Secdir Last Call review of -13 by Tom Yu
Genart Last Call review of -10 by Linda Dunbar (diff)
Intdir Last Call review of -10 by Brian Haberman (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
Comments
These are the reviews requested by the document shepherd.
Review State Completed
Reviewer Eric Vyncke
Review review-ietf-ippm-alt-mark-12-opsdir-lc-vyncke-2017-10-23
Posted at https://www.ietf.org/mail-archive/web/ops-dir/current/msg02914.html
Reviewed rev. 12 (document currently at 13)
Review result Has Issues
Draft last updated 2017-10-23
Review closed: 2017-10-23

Review
review-ietf-ippm-alt-mark-12-opsdir-lc-vyncke-2017-10-23

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