Skip to main content

Telechat Review of draft-ietf-ippm-alt-mark-13
review-ietf-ippm-alt-mark-13-opsdir-telechat-vyncke-2017-11-21-00

Request Review of draft-ietf-ippm-alt-mark
Requested revision 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
I-D 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
Request Telechat review on draft-ietf-ippm-alt-mark by Ops Directorate Assigned
Reviewed revision 13 (document currently at 14)
Result Has nits
Completed 2017-11-21
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