Skip to main content

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 revision No specific revision (document currently at 14)
Type Last Call Review
Team Internet Area Directorate (intdir)
Deadline 2017-09-27
Requested 2017-09-13
Requested by Spencer Dawkins
Authors Giuseppe Fioccola , Alessandro Capello , Mauro Cociglio , Luca Castaldelli , Mach Chen , Lianshu Zheng , Greg Mirsky , Tal Mizrahi
I-D last updated 2017-09-18
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)
Comments
These are the reviews requested by the document shepherd.
Assignment Reviewer Brian Haberman
State Completed
Request Last Call review on draft-ietf-ippm-alt-mark by Internet Area Directorate Assigned
Reviewed revision 10 (document currently at 14)
Result Ready w/nits
Completed 2017-09-18
review-ietf-ippm-alt-mark-10-intdir-lc-haberman-2017-09-18-00
* 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?