Skip to main content

Telechat Review of draft-ietf-tsvwg-ecn-experimentation-06
review-ietf-tsvwg-ecn-experimentation-06-opsdir-telechat-hares-2017-09-27-00

Request Review of draft-ietf-tsvwg-ecn-experimentation
Requested revision No specific revision (document currently at 08)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2017-09-26
Requested 2017-09-04
Authors David L. Black
Draft last updated 2017-09-27
Completed reviews Genart Telechat review of -05 by Brian E. Carpenter (diff)
Secdir Telechat review of -05 by Hilarie Orman (diff)
Genart Telechat review of -06 by Brian E. Carpenter (diff)
Opsdir Telechat review of -06 by Susan Hares (diff)
Assignment Reviewer Susan Hares
State Completed
Review review-ietf-tsvwg-ecn-experimentation-06-opsdir-telechat-hares-2017-09-27
Reviewed revision 06 (document currently at 08)
Result Has Issues
Completed 2017-09-27
review-ietf-tsvwg-ecn-experimentation-06-opsdir-telechat-hares-2017-09-27-00
This is an OPS-DIR Review which focus the work on issues in deployed technology
based on this RFC.

Summary: Has issues as guide to experimental RFC .  To me these operational
issues General comment: Thank you david for addressing this Area.  Better ECN
control is critical to many portions of the network.
                                   My comments on this draft are because I
                                   really hope you can do quality experiments.

How this might be resolved: if there is a operational guidelines section (or
separate document), that covered: a) how to set-up and determine if a ECT(1)
experiment success or fails b) how to manage your ECT(1) experiment in your
network. c) how to manage and detect if your ECT experiment is running into
problems with other IETF technology (TRILL, MPLS VPNs, IPVPNs, BIER and NV03
technology). d) Recommending a monitoring structure (e.g. yang modules,
netconf/restconf and monitoring tools0

Major issues:

#1 There is nothing in this document which provide guidelines to the authors of
experimental RFCs based in this draft on specific ways to
    monitor the ECN experiments, report the ECN experimental data, or disable
    the experimental data.   If the success or failure of an experiment is
    based on "popular vote" determined by deployment, then say state this
    point.  I personally would object to that
   because you cannot tell if a limited experiment in a specific location (E.g.
   a data center) might be successful in another location.

  If the success or failure of an experimental RFC is based on a specific set
  of criteria for ECN, then it would be good to give an operational suggestion
  on how to: a) design an experiment, b) run an experiment and collect data,
  and c) report ths
 data in order to standardize the ECN experiments using ECT(1).

 page 10 section 4.2 last 2 paragraphs in sentence, hinted that you have an
 experiment in mind without specifying the experiment's success or failure
 criteria other than popular vote.  Is this true?  if it is, this is
 problematic.  If I misunderstood your text, then please
have someone re-read the text.

I have read lots of papers on ECN.

2) No discussion was given on how the TCP layer experimentation would impact
routing layer handdlng of ECN.

For example, the trill WG has the draft draft-ietf-trill-ecn-support. 
Automated tunnel set-up for MPLS VPNS or IP VPNS may look at the ECN ECT(0)  or
ECT(1).  TRILL's ECN supports the layer-2 within the data centers.  Some IP
VPNS or MPLS VPNS may be needed for the data-center to business site
 or data-center backup traffic.

 As written, this draft allows loosening of the RFC3168 draft but does not
 provide guidelines  for network interaction.

3)  Some networks also use the diff-service markings to guide traffic in the
network.
    This document does not suggest an operational check list on how to design
    an experiment that supports or does not support these markings.

4) Modern operational IETF protocols and data modules for automating the
tracking of these experiments should be suggests

Editorial:
Some reviews have hinted that the text is repeats several sets of language.  
People have found this lacked clarity.  One wonders why the authors did not
simply provide a set of bis documents for RFC3168, RFC6679, RFC 4341, RFC4342,
and RFC5622 if it is just updating the language in the specifications.

This document tries to be both revision of the specifications and the
architectural guidelines for experiments.  The dual nature does not lead to
clarity on either subject.

I did not do editorial nits due to the higher level issues.