Last Call Review of draft-ietf-ippm-alt-mark-10
review-ietf-ippm-alt-mark-10-intdir-lc-haberman-2017-09-18-00

Request Review of draft-ietf-ippm-alt-mark
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Internet Area Directorate (intdir)
Deadline 2017-09-27
Requested 2017-09-13
Requested by Spencer Dawkins
Other Reviews Genart Last Call review of -10 by Linda Dunbar (diff)
Rtgdir Last Call review of -10 by Russ White (diff)
Comments
These are the reviews requested by the document shepherd.
Review State Completed
Reviewer Brian Haberman
Review review-ietf-ippm-alt-mark-10-intdir-lc-haberman-2017-09-18
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/l_u8zPqyNjyPwVmBHHWn_zb1mQQ
Reviewed rev. 10 (document currently at 12)
Review result Ready with Nits
Last updated 2017-09-18

Review
review-ietf-ippm-alt-mark-10-intdir-lc-haberman-2017-09-18

* The shepherd writeup mentions IPR 2557 in relation to this draft. However, the IPR declaration is only associated with the original individual draft. The IPR declaration needs to be updated to refer to the WG draft.

* The introduction says that this technique is needed to help monitor time & loss sensitive traffic. That would seem to indicate a need to associate these counters with individual flows. Has anyone done any calculations on how these counters will scale? Section 5 seems to indicate that there were only a few number of counters implemented via ACLs.

* The draft sets out to develop this technique without augmenting packet formats. That makes the statement in section 3.1.1 about how to color packets is out of scope a bit disingenuous. I would have preferred a brief description of the few available options on coloring packets in this section.

* The mention of maintaining timestamps for delay measurements is under-specified. Would the 32-bit NTP timestamp format be sufficient? The 64-bit NTP timestamp format? Guidance on how to carry out experimentation with this approach seems useful. Does the concept of adding timestamps per color block conflict with the first bullet of section 7 (only uses features already available on routers)?

* If the above statement on per-flow counters is not true, can I not accomplish the same capability by harvesting ifMib stats per interface and compare xmit/recv/drop stats across the network?

* The description of the Telecom Italia experiment references a 5-minute window per color. For time sensitive traffic like IPTV, how useful was the 5-minute reporting window? Were corrective actions taken prior to calls being handled by support?

* The Telecom Italia experiment writeup does not mention how the counters were harvested from the routers. Were readily available tools used to do this?