[tsvwg] Benoit Claise's Discuss on draft-ietf-tsvwg-ecn-experimentation-06: (with DISCUSS and COMMENT)
Benoit Claise <bclaise@cisco.com> Thu, 28 September 2017 08:24 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3979E1355A2; Thu, 28 Sep 2017 01:24:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org, shares@ndzh.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150658704722.13642.16407521705140305125.idtracker@ietfa.amsl.com>
Date: Thu, 28 Sep 2017 01:24:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/9vKMX64M8uBA5C-B5J5jdOc_3-k>
Subject: [tsvwg] Benoit Claise's Discuss on draft-ietf-tsvwg-ecn-experimentation-06: (with DISCUSS and COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Sep 2017 08:24:07 -0000
Benoit Claise has entered the following ballot position for draft-ietf-tsvwg-ecn-experimentation-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Below is Sue Hares' OPS DIR review. I would like to DISCUSS some points. I'm of two minds. On one side, I read: The scope of this memo is limited to these three areas of experimentation. This memo expresses no view on the likely outcomes of the proposed experiments and does not specify the experiments in detail. Additional experiments in these areas are possible, e.g., on use of ECN to support deployment of a protocol similar to DCTCP [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is limited to data center environments. The purpose of this memo is to remove constraints in standards track RFCs that stand in the way of these areas of experimentation. On the other side: An Experimental RFC MUST be published for any protocol or mechanism that takes advantage of any of these enabling updates. Btw, the MUST is just plain wrong, as Ben mentioned. So, if you go in the direction of providing requirements for the experiments (as opposed to just removing the specification constraints), then I agree with Sue. The document title goes in the direction: if it would say something such as "Removing constraints to the ECN experimentation", that would be a different story. Reviewer: Susan Hares Review result: Has Issues 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 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- And again, I can only agree with Sue's comment below, as stressed by Ekr and Ben also. However, this point was answered by Spencer and Mirja, so let's move on. 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.
- [tsvwg] Benoit Claise's Discuss on draft-ietf-tsv… Benoit Claise
- Re: [tsvwg] Benoit Claise's Discuss on draft-ietf… Black, David
- Re: [tsvwg] Benoit Claise's Discuss on draft-ietf… Susan Hares